- User-brennen is my personal workboard
- brennen-scratchpad is an Etherpad for miscellaneous notes
- I work on the Wikimedia Release Engineering Team
- Release-Engineering-Team is our team workboard
- RelEngTeam-Weekly (etherpad)
- Projects I work on:
User Details
- User Since
- Feb 3 2019, 8:29 PM (401 w, 3 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- brennen
- LDAP User
- Brennen Bearnes
- MediaWiki User
- BBearnes (WMF) [ Global Accounts ]
Today
(Disclaimer: I cannot remember the last time I personally ran a maintenance script in production, but it might well have been before mwscript-k8s.)
Yesterday
I'll roll forward during the UTC-7 window.
Thu, Oct 8
From Mozilla:
Submitted v3.4.0 of WikimediaDebug for review for both Firefox and Chrome. Not sure how long that'll take.
Tue, Oct 6
Thanks - it sounds like this fits the rubric. I set the visibility of plantilla-chatbot-patrones to private. Happy hacking!
Could you describe the plantilla-chatbot project?
Pasting in discussion from WMF Slack:
Fri, Oct 2
Train seems stable on all wikis, although I'm not thrilled with the current state of logspam and we'll be keeping an eye on T439902 next week.
I kindly request that my two WMDE colleagues @SuzanneWood-WMDE and @seanleong-WMDE are added to acl*Project-admins.
Thu, Oct 1
Maybe related to T402873: Create dedicated changeprop-jobqueue rule for CategoryCountUpdateJob - @Scott_French any thoughts?
Thanks!
Still seen in 1.47.0-wmf.22 (T438218). ~40 in the last 2 weeks.
Still seeing this in 1.47.0-wmf.21, 22. 55 in the last 24h.
I think this feels unlikely to be train-related, so not treating as a blocker.
No deploys around then, and I haven't yet found anything that changed recently with CategoryCountUpdateJob.php itself. I do see:
Wed, Sep 30
Error on rolling to group0:
Tue, Sep 29
Thanks for the risky patch notice @TheresNoTime. It's rare that we rollback test wikis, but if we need to, we'll revert https://gerrit.wikimedia.org/r/1343957 first (cc @brennen).
Mon, Sep 28
Verified via backchannel.
Tue, Sep 22
I think the filter added in T395728: 'Related GitLab patches' box includes patches for unrelated tasks (that begin with the current task's ID) is too strict and it ends up dropping legitimate matches like the ones above.
Sep 15 2026
Sep 14 2026
Sep 10 2026
Added your user to Trusted-Contributors based on on-wiki contributions. The GitLab account approval bot should pick it up shortly.
Aug 25 2026
Seems like the above change worked.
== Step 2: publishing == Successfully published image docker-registry.discovery.wmnet/dev/catalyst-base:0.0.2-s1 Successfully published image docker-registry.discovery.wmnet/dev/catalyst-code-server:0.0.3-s2 Successfully published image docker-registry.discovery.wmnet/dev/catalyst-mw-chart-base:0.2.0-s2 == Build done! ==
Aug 24 2026
Aug 21 2026
This is sick.
Aug 20 2026
Aug 19 2026
The remaining item here is now T435368: Migrate Patchdemo & Catalyst to PHP 8.5, Node 24.
This will be happening tomorrow at: https://zonestamp.toolforge.org/1787205600
Capturing from @jnuche in RelEng meeting chat:
User appears human and has an interest in a project hosted on GitLab. Not adding to Trusted-Contributors since I don't see a contribution history, but seems to meet the threshold for manual GitLab account approval. Happy hacking.
Please reopen if this is still needed.
Done.
Approved GitLab account based on a history of on-wiki contributions. Happy hacking!
Aug 18 2026
Noting here after discussion with @Aklapper that we're pretty sure the current https://phabricator.wmcloud.org is working correctly.
Aug 17 2026
Aug 13 2026
Looking stable on all wikis. Optimistically resolving.
Published.
Aug 12 2026
It's coming up on 17:00 local. Considering train parked overnight, pending a resolution on T434712. If no response from team there, a revert (as proposed by aaron on that task) seems like probably the way forward.