MediaWiki

Wikimedia Release Engineering Team/SpiderPig/Meeting notes/2024-10-17

< Wikimedia Release Engineering Team | SpiderPig | Meeting notes

2024-10-17

edit
  • Attendees: Ahmon Dancy, Jaime Nuche, Jeena Huneidi, Tyler Cipriani (All the folks <3)

TODOs

edit
  • Jeena can start working on the refactor
  • Jaime/Jeena to sync on steps
  • [x] Tyler to check in with design research for design support
      • [x] TODO: check with codex folks if this is even a good idea
      • TODO: bd808 django stuff
  • [x] Ahmon to start working on user flow through web-ui
  • TODO: Tyler refactoring hypothesis

Refactor

edit
  • Still seems like a good idea
  • Doesn't seem like a blocker
  • Should we keep it within the scope of this hypothesis or should we save for later?
  • JN: json/yaml consumed by spider pig will require some refactoring, which was in scope of the refactoring
  • AD: not a blocker for spiderpig
    • I would like to see improvements to checks of patches without running the full backport program, necessarily—get the patches straight for the user
  • JN: that's the data structure with all the validations
  • JH: call out to something _not_ scap backport to confirm dependencies? _Then_ call backport?
  • AD: Yes. Initially envisioned as a "queue" Without the queue (descoped) at this point, so that part is less useful.
  • JH: Scap backport would probably still have to use the dependency checker
  • TC: Moving to (tentively) next calendar year for refactoring work—not a blocker for phase 1 (phase 1 is: NOT Ahmon does backport via web page before end of calendar year)

Deployment of scap (splitting front-end and back...or something)

edit
  • AD: I'll get it working. We need to not use python3.9isms. Refactoring imports.
  • JN: non-trivial to split the front-end and back-end. Is the problem that it takes longer to install on the targets?
  • TC: I thought the problem was the dependencies?
  • AD: worked around that with newer version of pip

patches

edit
  • AD: 7 patches in the tree
  • JN: would be nice to chop this up into manageable reviews
  • TC: Web stuff in one big blob?
  • AD: Server side/Client side is current plan

Demo time!

edit
  • Started jobrunner, api server, npm run dev
  • Q: what's npm run dev ... do?
  • A: compiles vue files into a big javascript blob and starts a webserver to build. In future, we could run npm build at build time + extend api server to serve static site
  • Updates:
    • hooked into timers so we see status
    • Codex buttons in use

New Hypothesis Draft

edit

Old 'n' Busted:

If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments.

Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikimedia_Release_Engineering_Team/SpiderPig/Meeting_notes/2024-10-17&oldid=6802173"