MediaWiki

Wikimedia Release Engineering Team/Checkin archive/2024-01-24

< Wikimedia Release Engineering Team | Checkin archive


2024-01-24

edit

🏆 Winterrogation

edit
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Monthly_notable_accomplishments
Jan 2024
  • Gerrit train-dev fixed!
  • bd808's account approver thing seems working, maybe?
  • Dawned on Daniel & I that we could request extra Phab/Phorge hardware as backup
  • Deployed persistant volume cleaner
  • Docker images with pyenv with multiple versions of python
  • Worked with upstream phorge to hide the audit application (the post-merge review application for source code)
  • Webhook payloads for GitLab merge request changes—tracked down a bug in upstream
  • phab1004 distro upgrade is done
    • We know we can run in codfw if we have to (it sucks though, let's not)
  • scap clean now works better

Team Discussions

edit

Stuff from last time

edit

Docs!

Train security patch fixes

GitLab User Interviews

edit

Notes

Observations

edit

Gerrit, Phabricator, and Code Search are used as a single tool for us People seamlessly move from one to the other without thinking much about it This makes sense: the paid version of GitLab does all these things for a reason Repo browsing is a whole other topic My observation: This is an invisible barrier for newcomers Very few people mentioned benefits for newcomers (although there are some), but there is some scaring away of newcomers Reports of newcomers refuse to try Gerrit New people spin up on GitLab quicker Benefits to newcomers are negated by having to learn both Gerrit and GitLab There are already pain points from having two systems There were three examples of pieces of a single code base living in separate repos across Gerrit and GitLab already Submodules in Gerrit that are repos on GitLab Libraries in GitLab that are used in MediaWiki via composer Pipeline publishing images lives in GitLab, but the chart museum lives in Gerrit People are worried about their complicated workflow Two people said the opposite things: “that’s fine for (ops OR mediawiki) workflows since they’re simpler, but not for (ops OR mediawiki) because of the complexity” I think this means: my workflow is too complicated for this simplistic tool I think this quote sums it nicely: “Gerrit is better in projects that you need a lot of discussion and collaboration to get something merged”

Missing Things

edit

Stacking patchsets are used for more than large changes by a single author They’re useful for discussing implementation across several teams Stacking patchsets on other people’s changes as dependencies is common GerritLab (GitLab patch stacking tool we wrote) was a game changer for folks on GitLab, but it still has problems, notably for landing stacks of changes GitLab can get confused about the target branches in some unclear circumstances People still make errors on merge direction that GerritLab—Gerrit prevents merges all together, people rely on this When you have gating tests, you still have to merge in serial Watching: https://gitlab.com/gitlab-org/cli/-/issues/7440 Missing inline diff comments in GitLab You see discussion on a previous patchset, but only on the home page of the merge request When comparing with previous revisions, the conversation is not in context on GitLab, unlike Gerrit ...Still trying to recreate People rely on the view of the Gerrit dashboard to see relevant changes Nobody mentioned using custom Gerrit dashboards much, but almost everyone mentioned the Gerrit dashboard as their primary means of finding changes “Incoming reviews” and “Your changes” is the most useful People use search to help others Finding changes from someone mentioning they’re not getting any review Looking for reviewers for a new repo they’re contributing to New thought: the problem is, none of this is very discoverable in Gerrit There’s no good way to get an overview of relevant changes in GitLab Search features are not as expressive as gerrit—how do you search for reviewers? How do you find all open MRs of a single author? Tags/topics may be useful, but are unexplored Everyone mentioned multiple reviewers as a problem Several people mentioned unsatisfying workarounds People “@” one another to CC each other on changes but that doesn’t show up in your TODO list on GitLab Folks have experimented with using tags like 🦊 GitLab Needs review search This is missing the level of granularity that the default search in Gerrit can give you Also, doesn’t send an email to the reviewer asking for review which is one of the primary methods people use to find changes needing their review There were a lot of anti-patterns in our current use of reviewers It’s used for notification more than to request review Folks mentioned ambiguity about when things are ready for review It’s not how people get review on their patchsets—they rely on pinging other people in different channels (phabricator, email, team meetings) One person mentioned, if they’re added to a patch along with several others then they may not act until they have spare time Depends-on is used primarily for two things To prevent accidental merge As a method of communication Testing changes together in parallel was barely mentioned Very few mentions of the testing benefit, mostly in passing One person added “Depends-on” to unmerged library code where there is no testing benefit because the other benefits are so useful I wonder if people are even aware of the testing benefit(?) Approvals relying on unstructured, ad-hoc standards vs. "approved" "request revisions"

Slightly missing things

edit

Mixed feelings on “AttentionSet” and IRC notifications People who can mentally filter ambient noise seem to like the IRC notification, others mentioned avoiding them Lots of folks are confused about AttentionSet/”Your Turn” A few folks mentioned it was useful, but it was top-of-mind for no one



🌻 Open source/Upstream contributions

edit
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Upstream

📅 Vacations/Important dates

edit
https://office.wikimedia.org/wiki/HR_Corner/Holiday_List#2024
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Time_off (page needs updating for Dayforce)

Jan 2024

edit
  • 15 Jan: US staff
  • 15 Jan - 15Mar: Andre
  • 31 Jan - 2 Feb: Brennen

Feb 2024

edit
  • 16 Feb: Brennen
  • 14-16 Feb: Dan

Future

edit
  • 26 Apr: Brennen (tentative)
  • 1st Mar, 4th Mar - 8th Mar - Antoine
  • A few days around July 4: Brennen
  • 25 Aug - 03 Sep: Brennen


🔥🚂 Train

edit
https://tools.wmflabs.org/versions/
https://train-blockers.toolforge.org/
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar


  • 6 Mar – wmf.26 – Jeena + Jaime
  • 13 Mar – wmf.27 – Brennen + Jeena
  • 20 Mar – wmf.1 – Ahmon + Brennen
  • 27 Mar – wmf.2 – Chad Dan + Ahmon
  • 3 Apr – wmf.3 – Antoine + Dan
  • 10 Apr – wmf.4 – Chad + Antoine
  • 17 Apr – wmf.5 – Jaime + Chad
  • 24 Apr – wmf.6 – Jeena + Jaime
  • 1 May – wmf.7 – Brennen + Jeena
  • 8 May – wmf.8 – Antoine + Brennen (Ahmon out + Antoine Out 8th)
  • 15 May – wmf.9 – Ahmon + Antoine (Dan out + Chad out)
  • 22 May – wmf.10 – Chad + Ahmon (Dan out + Jeena out 26th)
  • 29 May – wmf.11 – Dan + Chad (Memorial Day 29th)
  • 5 Jun – wmf.12 – Jeena + Dan (Brennen out, Jaime out)
  • 12 Jun – wmf.13 – Jaime + Jeena
  • 19 Jun – wmf.15 – Cancelled for offsite
  • 26 Jun – wmf.16 – Brennen + Jaime (Jeena out)
  • 3 Jul – wmf.17 – Antoine + Brennen (3rd + 4th holidays)
  • 10 Jul – wmf.18 – Dan + Antoine (Ahmon out)
  • 17 Jul – wmf.19 – Ahmon+Dan (Brennen out Friday)
  • 24 Jul – wmf.20 – Jaime+Ahmon
  • 31 Jul – wmf.21 – Ahmon+Jaime (Jeena out, Antoine out) (Ahmon volunteered)
  • 7 Aug – wmf. 22 – No train
  • 14 Aug - wmf.23 – Ahmon+Jaime (Jeena out, Antoine out)
  • 21 Aug - wmf.24 – Dan(brennen out, Jeena out, Antoine out)
  • 28 Aug – wmf.25 – Jeena+Dan
  • 04 Sep – wmf.26 – Antoine+Jeena
  • 11 Sep – wmf.27 – Jaime+Antoine+Andre as lurker!
  • 18 Sep – wmf.28 – Brennen+Jaime
    • Logspam-watch needs some attention
    • Every deploy is rebuilding l10n
  • 25 Sep – 1.42.0-wmf.1 – Dan + Brennen
  • 2 Oct – 1.42.0-wmf.2 – Jeena + Dan (Jaime Out)
  • 9 Oct – 1.42.0-wmf.3 – Antoine + Jeena (Jaime Out)
    • Vector skin issue, backport this morning!
  • 16 Oct – 1.42.0-wmf.4 – Brennen + Antoine
  • 23 Oct – 1.42.0-wmf.5 – Ahmon + Brennen
  • 30 Oct – 1.42.0-wmf.3 – Dan + Ahmon
  • 06 Nov – 1.42.0-wmf.4 – Jaime + Dan
  • 13 Nov – 1.42.0-wmf.5 – Jeena + Jaime
  • 20 Nov – 1.42.0-wmf.6 – No Train
  • 27 Nov – 1.42.0-wmf.7 – Antoine + Jeena
  • 3 Dec – 1.42.0-wmf.8 – No Train offsite
  • 11 Dec – 1.42.0-wmf.9 – Brennen + Antoine (Jaime out)
  • 18 Dec – 1.42.0-wmf.10 – Ahmon + Brennen (Jaime out)
  • 25 Dec – 1.42.0-wmf.11 – No Train
  • 1 Jan – 1.42.0-wmf.12 – Dan + Ahmon (Jaime out)
  • 8 Jan – 1.42.0-wmf.13 – Jeena + Dan (Jaime out)
  • 15 Jan – 1.42.0-wmf.14 – Jaime + Jeena

[Jaime, Jeena, Dan, Ahmon, Brennen, Antoine][:-1]

  • 22 Jan – 1.42.0-wmf.15 – Antoine + Jaime
  • 29 Jan – 1.42.0-wmf.16 – Ahmon + Antoine(Brenen out Wed–Fri)
  • 05 Feb – 1.42.0-wmf.17 – Brennen + Ahmon
  • 12 Feb – 1.42.0-wmf.18 –
  • 19 Feb – 1.42.0-wmf.19 –
  • 26 Feb – 1.42.0-wmf.20 –

Let's do some inbox triage: https://phabricator.wikimedia.org/maniphest/query/7vRDrcVnt8OI/#R


Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikimedia_Release_Engineering_Team/Checkin_archive/2024-01-24&oldid=6534313"