In T247284#6022753, @Reedy wrote:

In T247284#6022727, @kaldari wrote:

@thcipriani - Any idea how to move a repo from Phabricator to Gerrit (without losing the history)? Or who would know?

Same way you would with any new git repo - add the new remote, and push everything to it ;)
With gerrit, you might need to enable force push/forge committer rights temporarily though

In T246793#6019857, @mmodell wrote:

this looks like it's likely the culprit: rMSCA3ca8820b7a68: Support for logging json to syslog

This stopped abruptly 21 days ago:

In T248922#6013632, @jcrespo wrote:

Either @thcipriani or SRE team would be the right people to own mwmaint servers, requesting his ok. Do you know if the requested access "deployment" is required to run maintenance scripts, or does "restricted" suffice for that?

Tentatively assigning to dduvall per IRC discussion

Is option 1 the only option that won't require some additional code that glues the moving parts together? That is, is a merge into master of the origin repo a deployment without any additional glue needed?

approved.

We have this switched off linting for the moment, planning on moving these plugins back into scap core Soon™. Lowering priority for the time being.

FWIW, the pausing and the error are two different pieces. That is, the pause is cdb rebuild IIRC. The error is sudo differences in beta vs prod.

In T216483#5958322, @MarcoAurelio wrote:

@thcipriani It's been a year since the last ping :-) Do you object moving this to Gerrit? If not, which repo name should we use for this one? Thanks.

Thank you @Aklapper

Hi @Soda sorry this took so long :(

In T245185#5980803, @LarsWirzenius wrote:

Same as T247075?

This one:

Added wmf.23 as a blocker for wmf.24. If wmf.23 isn't fully deployed by the wmf.24 Tuesday train window then we should go ahead and cut the branch for wmf.24, but NOT deploy it to any wikis. This unblocks folks waiting to merge to master until after wmf.24 is cut, but spares us the confusion of 3 branches in production which I definitely want to avoid.

Also the things I see in the changelog that mention "cache" are...many things: https://www.mediawiki.org/wiki/MediaWiki_1.35/wmf.23/Changelog

I'm trying to figure out if this is an actual code change or a memcached server problem with bad timing. Or maybe it's a code change that causes memcached to have a bad time? Does anyone have a theory there?

FWIW, ran some tests with apachebench today and the patchset on this task and it didn't seem to make requests significantly slower or load significantly higher in my rudimentary testing:

Updated chart, calling this complete.

This hasn't happened today afaict:

In T246763#5959785, @Lucas_Werkmeister_WMDE wrote:

• https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php72-docker/25459/console, for https://gerrit.wikimedia.org/r/578335

Updated post team meeting with actual blockers.

Lowering priority since this hasn't happened once in the hour I've spent investigating according to the access logs.

Looking specifically for upload-pack errors that happened over https in the past 30 days (this is what zuul would be using)

Strangely, I'm not seeing the graphs in gerrit monitoring reporting a rise in error rate (this counts 4xx as well as 5xx so maybe it's lost in the noise). Logs are also not showing a massive increase in the error rate @Lucas_Werkmeister_WMDE did you run into this on one repo in particular? One job in particular?

Back after restart. I didn't get an alert aside from this task. Filed as T247186