On Mon, Mar 04, 2019 at 09:40:32AM +0100, Vít Ondruch wrote: > > Dne 02. 03. 19 v 8:09 Adam Williamson napsal(a): > > 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. > > > These were my first thoughts as well. > > Also, how are the mass rebuilds envisioned? Just as anyone would: by opting-out of gating. Maybe that term is overloaded. The way I see it there are two ways to opt-out: - remove the gating.yml file in the package's git repo, not scalable especially for mass-rebuild - build in the koji candidate tag directly, thus by-passing the testing tag where tests happen. This would be the approach releng would do for mass-rebuild. > I can't imagine that Ruby > rebuild will be held from entering rawhide due to some broken > dependency. Not sure how you want distinguish the package, which is > typically "single" from "multi" package. This is a decision left in the hands of the packagers, I'm pretty sure they know more their packages than I do and thus I'm in no position to make this decision. Does this help? 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
