Re: Gating packages in Rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 28, 2018, 12:53 Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux