On Sun, Jun 20, 2021 at 12:31 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Sun, Jun 20, 2021 at 7:10 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > > > 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. > > > > Most of our rules are designed to make sure there's someone ultimately > responsible for everything going into Fedora. Unfortunately, bots are > the opposite of that, because there's no one to reach to stop bad > behavior when it happens. So that should be fixed so that each bot has a contact so that problems have means of escalation. > Rawhide is still not your CI environment. Years ago, we got rid of > alphas for the express purpose to stabilize Rawhide into alpha > quality. Stuff like this degrades the quality of Rawhide because they > make the assumption that nobody cares about the quality of Rawhide. Being one of the people driving that in rel-eng at the time, the other was dgilmore, that statement is incorrect. The dropping of Alphas was because we improved the compose to produce all release artifacts on the nightly composes, both rawhide and branched, instead of just the network installer and live images. Previously to that we only produced all artifacts with the TC/RC composes, we also got rid of the TCs as part of that process. > If you want the features of Rawhide for CI, then we should talk about > enabling this in more places. For example, there's no technical reason > we couldn't do OpenQA runs for packages in COPR. There are serious > consequences to shipping packages into Rawhide, not the least of which > is that it locks an NVR forever into Koji and ships it to people using > Rawhide as a daily driver. Also having the ability to have COPR I don't see why any of that is a problem. Of course having decent working gating would also assist in that. > auto-rebuild as stuff changes in the build root makes the CI case work > better, and that's something we literally can't do in Koji (by policy > and by design). _______________________________________________ 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
