On Wed, Mar 28, 2018, 14:51 Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
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.
That's true, but I'm not sure making the update process more complicated is worth the benefit of having test results in one place.
> 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.
One example where running tests against a single-package update would be nice IMO would be for toolchain and base packages, for example, updates to annobin or binutils, where the answer to "Does this update break compilation with GCC?" (which could be added as a test case) would be vital in determining if the package should be pushed to rawhide or not.
Hope that makes it more clear what I meant by "it also would be nice for single-package updates".
Pierre
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
