One roadblock to merging them is that that the CI might not work anymore: T113725: job analytics-wikistats has zuul trigger but vanished from integration/config

I might be able to give a "+1 I would merge this" on some of them. But even if I had permission to +2 them the deployment would still need to happen. No use in changing it and not putting it live, that just makes life hard for the next deployment. I found no documentation (e.g. at https://www.mediawiki.org/wiki/Analytics/Wikistats ) about how to deploy this, so here my attempt at finding out, based on my reading of the puppet leafs:

There is probably a checkout of that project on stat1002.eqiad.wmnet under /srv/wikistats_git but its creation and update is not puppetized and I found no indication about automation for it. Similarly I find references to /srv/stats.wikimedia.org but nothing that creates it. Maybe I missed something. If not it would be worthwhile to improve that a bit. But again to deploy those improvements it is a good idea to have the people who know how to deploy changes there sanity check that.

There is probably a checkout of that project on stat1002.eqiad.wmnet under /srv/wikistats_git but its creation and update is not puppetized and I found no indication about automation for it. Similarly I find references to /srv/stats.wikimedia.org but nothing that creates it.

They are on stat1003 actually, and not updated since 2013 so that's probably not where the actual wikistats lives.

I use the WikiStats code on my own server for non-Wikimedia wikis, so I actually care about merge even without deployment. :)

@Analytics: Who should be the assignee of this task?

In T113695#1676786, @Tgr wrote:

so that's probably not where the actual wikistats lives.

Sounds like Analytics-Engineering need to check https://www.mediawiki.org/wiki/Analytics/Wikistats and potentially update it, as one outcome for Wikimedia wikis.

Oh I missed that stats.wikimedia.org is served by stat1001 (according to the misc varnish config), so there is a 3rd host that has parts of this around.

Some info on these Wikistats issues:

1 Wikistats runs on two servers

stat1002 for monthly reports, using stub dumps
stat1003 for additional metrics only available from full archive dumps (word count, links, trends in avg page size). As these dumps are insanely huge this happens on a much slower cycle

(right now I don't seem to have access to stat1003 via putty, but the job runs since long without interruptions)

2 Most monthly jobs run from my home directory on stats1002

Also on stat1002 is /a/wikistats_git/ which used to be the place to run jobs from, but there were push issues (this dates back to before gerrit), and at that time no-one knew why, so I couldn't update bash files from there, etc

3 Obviously running from home dir is not ideal for others when they need to take over in an emergency.
More things are not up to par for Wikistats, but Wikistats is going to be made obsolete at WMF asap (actually since hadoop arrived, 4 years ago, but real soon now). As I work 1/3 FTE (by own request) I have to set priorities. Restructuring code is not one of them. Helping Wikistats be superseded should be one of them, and I'm eager to help with that.

Nothing is puppetized, BUT as I said Wikistats is near end of life at WMF, so better not bother with puppet (preserving the code base is another thing of course, if only for @Nemo_bis)

4 For a year my git repo wasn't updated, some lingering sync issues. Some months ago @Milimetric helped me to cleanup my totally out of date git repo. Which was great, and I want thank him once again! So now all my code is in git and Nemo's code as well, as far as I know, please correct me if I'm wrong. So my understanding is those gerrit tasks are obsolete. I'm back to pull/push and no longer use gerrit myself (burn me).

Thanks

So my understanding is those gerrit tasks are obsolete.

At least one I tested is not obsolete. https://gerrit.wikimedia.org/r/#/c/92066/ cleanly rebased to master and still had content (I did that locally and didn't push the rebase).

In T113695#1680652, @ezachte wrote:

More things are not up to par for Wikistats, but Wikistats is going to be made obsolete at WMF asap
[...]
So now all my code is in git and Nemo's code as well, as far as I know, please correct me if I'm wrong. So my understanding is those gerrit tasks are obsolete.

Thanks for elaborating! From a quick comparison of a fresh git checkout of analytics/wikistats and the five unreviewed patchsets in Gerrit, I don't see any of those five changesets fully reflected in the git codebase. So they don't seem to be obsolete to me.

@ezachte: What would be the plan forward to make decisions on these five proposed changesets in Gerrit?
Do you plan to review those? Or is the repository "deprecated" from your point of view and nobody should provide any patches to that codebase anymore? Or something else or in-between?
Thanks for your help!

@ezachte: Could you answer the last comment please?

Sorry. @Aklapper I missed your previous comment. And @JanZerebecki answering yours is still on my list.

This week I will have to focus on T114379, as that one has been prioritized and others depend on my input. But I will follow-up on this one.

There is a proposed WikiDev16 session about improving code review, especially for volunteers: T114419: Event on "Make code review not suck". You are welcome to comment there if interested.

In T113695#1705220, @ezachte wrote:

This week I will have to focus on T114379, as that one has been prioritized and others depend on my input. But I will follow-up on this one.

@ezachte: Any vague timeframe? :)

I reached out by mail to @Nemo_bis with comments on each open patch.

@Nemo_bis says this may have to wait till Feb
in the meantime I can look further into '[Full dump analysis] Reduce edits_only and reverts_only intricacy'

closed https://gerrit.wikimedia.org/r/#/c/92056/ -> 4/5 open