On 03/02/21 14:29 +0100, Kevin Kofler via devel wrote:
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
No.
then need to revert rawhide to rawhide-build, which is not easily automated
No.
(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.
You've completely misunderstood the suggestion. I'm suggesting that
everybody pushes to rawhide just like today. Maintainers and
provenpackagers. Nothing changes in that respect. There is a read-only
branch called rawhide-build which contains the last-known-to-build
commit from rawhide. Nobody can push to rawhide-build, it only gets
updated automatically when a build completes in koji.
If a maintainer wants to fix the broken state they created, they just
fix it locally and push. There's no need to reset or merge in the
revert that happened upstream (because that would be extra work for
them, and non-trivial to do right for devs who aren't comfortable with
Git beyond the basics).
If a provenpackager needs to bump and rebuild they have choices (but
none of them involve touching rawhide-build as that's read-only):
1) Do nothing. The package is broken anyway. The maintainer needs to
fix it anyway. It will be rebuilt after they fix it. Why should the
provenpackager fix it? Often they don't need to. This is less work for
the provenpackager, and leaves the rawhide branch in the state where
the maintainer last touched it, so they can easily start fixing it.
2) Proven packager *manually* does git revert for the commits that are
on rawhide but not rawhide-build (which is an easy way to know which
commits were added since the last successful build). Or soft reset to
rawhide-build and commit. This is appropriate when the provenpackager
needs the rebuild in a side tag because other packages that depend on
it also need to be rebuilt. This still makes things harder for the
maintainer who wants to fix the package, but if the provenpackager
really needs the new build, this gets them there. The history is
still inear (no force push anywhere) so the maintainer can still
re-apply their changes (or revert the revert) and then fix them.
Sometimes option 1) will be appropriate, sometimes option 2). Making
the reset/revert automatic doesn't give anybody a choice. Both options
ensure a linear history, no rewriting with force push.
I'm very strongly opposed to having automated force-pushes on the
rawhide branch to reset it to an earlier state. That doesn't just hurt
the maintainer who pushed the broken work, but anybody (including
provenpackagers) who fetched it before the history is altered.
I'm opposed to automated 'git revert' on rawhide (but not as strongly
as force pushing to public branches).
_______________________________________________
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
