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: > > https://fedoraproject.org/wiki/Changes/GatingRawhideSinglePackageUpdates > > > > == 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 > tests). 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 > Rawhide. 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). Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
