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.