Jonathan Wakely wrote:
> Instead of force pushing or reverting anything in the rawhide branch,
> why not just have two branches?
>
> Maintainers commit to one branch, and if the build is successful that
> branch is automatically merged (as a fast-forward merge) to a
> "rawhide-build" branch.
>
> That way you know that what's on the rawhide-build branch was able to
> successfully build (at one time ... it might fail later due to changes
> to other packages).
>
> That avoids any automated (and possibly error prone) resets or reverts
> on the branch that the maintainer pushed to.
But it means that provenpackagers who want to bump and rebuild have to
actually manually look at another branch (rawhide-build). Plus, they will
then need to revert rawhide to rawhide-build, which is not easily automated
(and they cannot just reset and force-push, which would be the easy way,
because the git hooks prevent that). So, compared to my proposal, your
proposal pushes work away from automated infrastructure to packagers
(breaking their mass rebuild scripts, which is the whole point of this
thread), and makes it impossible to use force pushes (or at least
impractical: how should the exception in the git hooks be implemented?
Whereas exempting pushes submitted by the CI infrastructure would be
straightforward).
Hence, I cannot see how your suggestion would be an improvement over mine.
Kevin Kofler
_______________________________________________
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
