> With things like [0] (TL;DR: bots submitting broken builds to rawhide) > becoming a more regular occurrence, I propose that we extend the > existing Updates Policy [1] to make it explicit that bots are not > allowed to submit builds / updates - even to rawhide - unattended: > "Rawhide is not your CI environment." I don't think that's good for either the packages that are using bots or for Fedora as a whole. While the bots certainly don't always get it right nor do the humans and I would garner that there's a lot more problems introduced in this way by humans, over the years I've spent considerable time fixing issues like this introduced by humans. Do we ban humans too? Do we ban RHBZ bots as well because they don't always get it right either? Ultimately automation is hard, but ultimately I feel it generally gets it wrong no less than humans do, and generally in a consistent way at least. > Currently, the Updates Policy states: > > - packagers must verify that no known broken builds are pushed, > - packagers must announce ABI and API changes once week in advance, > - packagers must not push pre-release versions of low-level packages. > > While it is debatable whether podman + friends + > container-stuff-dependencies count as "low-level" packages, they *are* > installed by default in Workstation. I think it is clear that by using > a bot to automatically push pre-release snapshots as rawhide updates, > the first two requirements CANNOT be met. > > I would like to make this conflict explicit and add a statement like > this to the Updates Policy: "Automated systems / bots are not allowed > to submit new builds for inclusion into Fedora without the involvement > of a packager." Please no. > The following things should still be allowed: > - releng and SIGs submitting scripted mass rebuilds (no actual package > changes, triggered by a person) > - bots submitting rawhide builds for ELN (no package change, just > built for different buildroot) > > The following should be explicitly banned: > - bots submitting new, non-scratch snapshot builds of software to > rawhide unattended (often leading to broken versions, versioning > snafus, or blatant errors leading to package downgrades, as it > happened today [0]) The problem with this is we will likely drive away contributors, packaging takes a lot of time, especially if you've got a stack of packages that are part of a group. Over the years there's been a bunch of effort all over the place to automate some of this, from tito, the upstream monitoring project thing (the new hottness or what ever it's called), packit and the rh container bot. None of them are perfect and all have their quirks. I would much sooner an officially support/ed/sanctioned auto packaging bot that upstreams can integrate into their projects to do automated packaging so they can get on and do more useful work either upstream or within the project. With something that is a "one true automated way" it would at least be consistent in the results. > There is already a requirement that no packager should submit builds > that are never intended to go "stable", and I see this as a similar > requirement - since those snapshot builds are presumably only done for > automated CI purposes without the intention of them ever reaching > stable Fedora releases, where they are superseded by packager-created > manual builds of those packages - but leaving Rawhide with unstable, > bot-created snapshot builds. I find the automated builds, in conjunction with OpenQA testing, very useful for IoT as they've caught a number of issues with upstream which likely wouldn't have been caught before the release goes stable and hence gets into stable IoT releases, it doesn't catch everything but the more it catches the better off the project is as a whole. I would much sooner the effort here goes into a sanctioned package build bot than trying to ban things TBH. Peter _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
