Merge pdbq:planned-merges-mm into pdbq:main
Status: | Merged |
---|---|
Merge reported by: | Bryce Harrington |
Merged at revision: | bf7caad13f3446e500fd458f1d9c03b494ebc9ea |
Proposed branch: | pdbq:planned-merges-mm |
Merge into: | pdbq:main |
Diff against target: |
450 lines (+70/-183) 4 files modified
pdbq/text.py (+2/-8) scripts/planned-merges (+14/-144) scripts/refresh-data.cron (+11/-8) scripts/usmerges (+43/-23) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Athos Ribeiro (community) | Approve | ||
PpaDevTools Developers | Pending | ||
Canonical Server | Pending | ||
Canonical Server Reporter | Pending | ||
Review via email: mp+442500@code.staging.launchpad.net |
Description of the change
Some backend changes to pdbq for the merge board preparations.
The main thrust of this branch was integration of upstream data that's
now being generated by the `collect-watch` worker into the `usmerges`
backend script. collect-watch was rewritten from Bash to python this
last cycle and received a number of improvements in the process,
including switching the output format from text to JSON. So usmerges
is updated to now consume this JSON instead of custom parsing text.
Before:
https:/
After:
https:/
The second thrust of this branch drops much of the "predictive
scheduling" functionality from `planned-merges`. This had proven to be
mostly inaccurate (thanks COVID era) and of limited actual value in
practice. While the improvements to collect better upstream data helps
address part of the former problem, the latter problem still trumps.
Users prefer to have the 'no-merge-
handled manually. So instead of trying to (incorrectly) guess when
these merges might come to be, efforts will focus on automating the
detection of when they DO show up. The server team has been effective
at processing these on the fly when they come up in the housekeeping
meetings, so we can rely on that workflow instead.
Beyond that is assorted cleanup work and bug fixes to allow the merge
board data to be generated.
There was an error fetching revisions from git servers. Please try again in a few minutes. If the problem persists, contact Launchpad support.
Thanks for the improvements, Bryce! I really like the changes to the strings in the merge bugs :)
I added a few comments inline below.
Also, the semantics of fe31b85d5bc2fec 96d784ffa583cc1 153888dc50 commit message seems to be inverted. It says "planned-merges: Use - instead of _ in JSON variables" when it seems it should say "planned-merges: Use _ instead of - in JSON variables"
Apart from the commit message, which seems to have the opposite intended meaning, everything LGTM and all my other comments are mostly nitpicks. Therefore, I am approving this one to avoid blocking you any further. Feel free to merge this before or after addressing any of my comments :)