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). > == 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. 2) This does not consider the not uncommon case that updates *should have been* multi-package updates, but they were done wrong. > When considering gating rawhide package updates on test results, we > need to consider two workflows: single package updates, multi-package > updates. This proposal only considers the single package updates > workflow. [[Changes/GatingRawhideMultiPackagesUpdates|Another > proposal]] will be submitted in the future to support the multi > package updates workflow. > At first we want to build the system allowing to gating rawhide, > packagers will '''opt-in into gating''' > [https://docs.pagure.org/greenwave/package-specific-policies.html > using greenwave's opt-in gating mechanism] as they want. We will also > offer a way to '''opt-out''' so packages depending on other packages > can still be built without issues. > > We do not aim at making any tests mandatory as part of these > proposals. Once the two proposals have been deployed it will be up to > the community and likely FESCo to decide if they would like to enforce > some rules on all packages and which ones. > > Note that this proposal completes previous initiative such as > [[Changes/NoMoreAlpha]] That Change envisaged *both* package build gating *and* compose gating, so this alone does not really complete it, for the record. > ==== Bodhi ==== > > * 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? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
