So, you list 3 typical reasons why packages in rawhide FTBFS and 2 existing policies which are meant to prevent 2 of these 3 reasons if packagers followed these policies. And you want these policies to be enforced technically What I am missing is: - A viable suggestion on how to prevent the third reason (pushes for sidetag builds, your #2.) within your proposal. - Any mentioning of what provenpackagers could do to avoid conflicts. I completely agree that FTBFS in rawhide is annoying. But not every policy can be enforced technically. We have scratch builds for PRs in dist-git, which is great. But (if this hasn't changed lately) I cannot fork my own dist-git repo and file a PR, so I cannot use that to communicate my intentions to a provenpackager nor to my co-maintainers. I cannot even use that to build into a sidetag. I think it's quite simple - If I as a maintainer break it I need to fix it, that's the deal. And as Fedora packagers we have a *lot* of infrastructure at our disposal (koji, koschei etc.) which helps us with that task. If there are rough edges (such as the one mentioned above) we should work on improving the tools. Personally, my packages FTBFS only when there is a change in the compiler chain or a library or rpm build macros or such. No technical solution that checks my pushes would prevent those FTBFS or even alert me to them. OTOH, sidetag or copr builds such as done for upcoming python versions are a great way to alert packagers before everything breaks on rawhide. _______________________________________________ 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
