On Sun, Jun 20, 2021 at 10:55:00AM +0200, Fabio Valentini wrote: > On Sun, Jun 20, 2021 at 10:45 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > > > I think this is a good idea. This particular bot has a history of misbehavior > > and rather than banning all the well behaving bots (that be definition we don't > > even know about, because they behave good), we should disable this particular one. > > > > Rather than "no bots allowed" policy, we might need a "bots that violate our > > policies and guidelines or have a tendency to break things will be disabled > > until fixed" policy. > > Yeah, that works for me too. Though I wouldn't want to make this a > special case and create an actual policy for this instead, that we > could point to when something like this happens. > > I also think that I probably was not clear in my original message. > > Any builds that are triggered by an actual human action, like > - scripted (mass) rebuilds with no *Version* changes, > - automatic builds after human-approved PRs, > - etc. > are of course exempt, because the action of an actual human being > triggered them. > > The only thing I *don't* want is: Bots submitting builds for new > *Versions*, without human interaction. So... what about new versions of clamav-data? I'm pretty sure that's OK to bot-ize. Then what about new minor version of thousands of rust packages? If we have %check sections and CI and gating, the act of releasing the update as a packager is not much different than a what a bot would do. Right now we mostly don't automatize this, but I think we could in the future. > Regarding Zbyszek's point: > > > Second, I think the guideline is simply wrong. As counterexamples, we > > currently have python3.10beta2 in rawhide, systemd-249-rc1, and > > kernel-5.13.0-0.rc6. Pushing pre-release vesions of low-level packages > > is a crucial part of development of the distro and collaboration with > > upstream projects and language ecosystems. > > There's actually already an exemption in the Updates Policy for those cases. > And I don't have any problem with those, because those builds are > prepared, built, tested, and shepherded by actual humans, instead of > created by a bot that just throws them at the wall to see what sticks > and what doesn't. Oh, OK. I didn't look at the policy page, just went by the quote provided. > If you look at bodhi updates for rhcontainerbot it's pretty obvious > that nobody even looks at the updates that are created for those > builds: > https://bodhi.fedoraproject.org/updates/?search=&status=testing&user=rhcontainerbot > It looks like any build that receives -1 karma or fails gating tests > will just be stuck in "testing" until obsoleted by the next automated > build for that package. Yeah. I'm looking a the original ticket in https://pagure.io/fesco/issue/2228, and I think this was a mistake. We shouldn't have approved a bot that packages snapshot commits for rawhide. In the discussion, we talked about load on the infra, and ability to contact the maintainers, and even cooperation withb packit, but somehow the question whether we want this at all didn't come up. I guess the effort to make rawhide palatable hadn't really sunk in deep enough back then ;) @lsm5, would you be willing to adjust the bot to only package actual releases? Also, what is going on with the version jumps? Zbyszek _______________________________________________ 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
