Hi, On Sun, Jun 20, 2021 at 1:30 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. > > Rawhide is still not your CI environment. By the way I think we need to reconsider this statement. I think I understand the intent, but the statement itself is misleading, if not wrong, when taken out of context. For a person outside of the bubble it is hard to understand and it seems to be contradicting with the idea of Rawhide being the integrated development branch of the Fedora Linux distribution. While normally we do use words "CI" as a replacement for the word "testing", we should be more careful in official statements and policies, or at least should provide the context and explanation, rather than just a slogan. > 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. And I'd rather see us writing the requirements for the things themselves, which supposed to land in Rawhide, than requirements on the implementation of _how_ these things get there. > 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 > 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). > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > 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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
