Good morning!
Based on the outcome of this discussion, I started trying to draw how the
process to update a package in rawhide would look like with rawhide being gated
on tests.
There are currently two proposals:
- one that does not involve bodhi updates
- one that does
Both proposals have a different flow for single-package update and
multi-packages update.
Here is what I came up with.
Without bodhi:
- Single package update
https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide.png
- Multi-packages update
https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs.png
With bodhi:
- Single package update
https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png
- Multi-packages update
https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_MultiplePkgs_bodhi.png
Outside of this workflow things we know we want to have/keep working:
- Keep chain-build working
-> would one of the proposal facilitate that?
- Have a way to run tests against an entire side-tag before merging it
- Have a way to ask the tools to re-check greenwave's decision (so that false
negative can be waived and the process continued)
mizdebsk suggested on IRC two ideas which I think would be worth looking into
a little bit down the road once we got the basis done:
- new side-tag could be automatically generated from fedpkg build command
- packagers could define a list of packages that should be rebuilt in the
side-tag and when all of these packages have been successfully rebuilt, the
request to merge the side-tag is automatically created
This would allow to use chain-build and let the entire process be automated.
What do you think?
Looking at your two(four) suggested workflows, they look very similar - there's just bodhi sitting between components in the second case, acting as a MITM, but not really adding anything useful compared to the case without bodhi (please correct me if I am wrong).
So, just to state my opinion (with my packager hat on), I would prefer the first case: without involving additional bodhi updates for rawhide builds. Additionally, these workflows also closely resemble the current workflows for submitting packages to rawhide, which is nice.
Whichever direction fedora will choose in the future, I think being able to test single updates before tagging them to rawhide, and especially being able to run tests against whole side-tags, would be a huge improvement over the status quo, and would especially improve the stability and "composability" of rawhide (and would probably cut down on the notorious number of fedora release delays, as a result).
Fabio