On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon <pin...@pingoured.fr> wrote:
> Good Morning Everyone, > 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 > Pierre > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
