On Fri, Mar 01, 2019 at 11:09:48PM -0800, Adam Williamson wrote:
On Fri, 2019-03-01 at 16:19 -0500, Ben Cotton wrote:
> == Summary ==
> We want to gate packages on test results before they can land in
> rawhide. This will reduce the amount of broken dependency,
> uninstallable packages and broken composes leading to a more stable
> rawhide as well as less work on the infrastructure and rel-eng teams
> to keep composes working.
> This project will be split in two phases, at first only single package
> updates will be supported, in a second stage, we will add support for
> multi-packages updates.
> This proposal is about the phase 1 of this project.
> == Owner ==
> * Name: [[User:pingou|Pierre-Yves Chibon]]
> * Email: pingou - pingoured.fr
> People who are/will be involved in this:
> * Coordinator: [[User:pingou|Pierre-Yves Chibon]]
> * Bodhi: [[User:bowlofeggs|Randy Barlow]] and [[User:abompard|Aurélien Bompard]]
> * Fedora CI: [[User:dperpeet|Dominik Perpeet]]
It might be a good idea to have a QA contact here, in case people
choose to block on tests maintained by the QA team (Taskotron or openQA
Yes and no, yes I'm all in favor of having a contact person from QA to help
volunteer to pick up the right tests for their package, but no as which tests
are used to gate is out of the scope of the proposal itself.
I'd be in favor of adding something like:
If you want to volunteer to opt-in into this workflow and need help figuring out
which tests would be interesting to run in your package, contact foo at
<email/list> or open a ticket at <tracker>
Would that make sense?
If so, where should we recommend packagers to get help?
> == Detailed Description ==
> Querying the Bodhi database, it was revealed that 95% of all our
> updates involve a single package.
> To be exhaustive, here are the exact number found by Randy:
> Of all time:
> Single build updates: 123,657 (94.1%)
> Multi build updates: 7,766 ( 5.9%)
> Total: 131,423
> Per release:
> Fedora 29:
> Single: 4,675 (93.7%)
> Multi: 316 ( 6.3%)
> Fedora 28:
> Single: 9,153 (94.5%)
> Multi: 536 ( 5.5%)
> EPEL 7:
> Single: 12,664 (94.0%)
> Multi: 814 ( 6.0%)
I'd suggest the implication that single-package updates are "the norm"
is slightly problematic, for two reasons:
1) Rawhide is very different from stable releases, and even from
Branched. Major changes like API breaks are not meant to be sent to
stable releases at all, by policy. So I don't think you can necessarily
rely very strongly on data regarding updates in Branched and stable
releases to draw conclusions about the likely nature of changes in
This is fair, but plays on both side, we're also supposed to send more updates
to rawhide than to stable releases. So there will be more multi-packages updates
in rawhide but also more single-packages updates.
While we may not be at 95 to 5 in rawhide, it is still expected that single
package will be much higher.
2) This does not consider the not uncommon case that updates *should
have been* multi-package updates, but they were done wrong.
That is true, I believe that by only onboarding packagers who want to (opt-in)
and providing a way to by-pass (opt-out) we should be able to cope with this.
> * Single package update
> ** We will need to write a message-bus listener that will
> automatically create a bodhi update for each package built in the
> rawhide-gated tag.
Does this mean that the plan has changed once again and it will no
longer bypass Bodhi and use side tags and integration with fedpkg?
We have considered a number of options, one of them was to no involve bodhi but
it had a number of disadvantage for Fedora for a similar level of work (amount
and complexity) which made us choose to keep bodhi involved.
Using side-tags and changes to fedpkg will be required for gating multi-packages
updates, they are not required for single package updates (there is a link in
this proposal to the follow-up proposal for multi packages updates, do note that
this is still a draft and thus may change when we get to this workflow).