On Wed, Mar 28, 2018 at 11:16:35AM +0000, Fabio Valentini wrote: > On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> > wrote: > 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). They are quite close indeed. > 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. That is also my take on it, but including bodhi has also some benefit, one of which is that test results for rawhide and stable releases end up there instead of having test results for rawhide in src.fp.o (and bodhi for the case of multi-packages) vs bodhi for stable releases. > 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 I think being able to run tests on a side-tag before request for it to be merged is a good feature, I am less sure about this for single-package. Could you expand? My take is that for single package: you build it, if tests pass it goes into rawhide (as today) if they fail, it doesn't go anywhere and as packager we can either fix the issue, waive their results and/or fix the test. Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
