On 04/02/21 05:03 +0100, Kevin Kofler via devel wrote:
Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote:
But it means that provenpackagers who want to bump and rebuild have to
actually manually look at another branch (rawhide-build).
No, why would they need to do that?
Because the whole point of the thread is that they need to bump and rebuild
from a state that already builds. Otherwise, why would we add the CI to
begin with?
The question aside, they wouldn't be allowed to do that, anyway.
Surely they would be allowed to LOOK at the branch, and hopefully also to
check it out (read only), otherwise why create that branch to begin with?
The idea is that only CI can push there once there's a successful build
from rawhide branch.
And that is exactly what makes the whole idea worthless. Provenpackagers
need to bump the branch that actually builds and then push that to rawhide.
Not always. Sometimes if a package is already broken in rawhide, then
I'm quite happy to just skip it during my rebuilds.
This only works in a useful way if the branch that actually builds IS
rawhide.
Plus, they will then need to revert rawhide to rawhide-build,
Again, why?
Because, by definition, rawhide-build compiles and rawhide might not.
And the rawhide-build ref tells you the last state that builds, so you
can easily compare it to rawhide. It could be just a tag that gets
moved with git tag -f every time there is a successful build, but I
think a branch ref might be simpler (it's no more overhead in Git, and
doesn't depend on --no-tags or branch.rawhide.tagOpt).
I'm not suggesting a solution to "provenpackagers need to build things
that might be broken". But I don't think automatically
reverting/resetting the repo after a failed build is a good solution
to that either, and it has provable problems (rewriting history with
resets and force pushes will definitely cause friction and problems
for maintainers).
What I'm suggesting is non-destructive, but gives us an easy way to
find the last-known-good commit in dist-git. Your suggestion is
destructive and doesn't give us that. If I do a git fetch *while a
build is ongoing* I don't know if it's broken or not, I have to wait
for the build (which I might not even know is happening). So I might
fetch+bump+rebuild and it still fails, and then I have to fetch and
discover history has been rewritten, and reset, and try again. And
maybe that's still racing with an attempt to fix it from the
maintainer, so it fails again, and history gets rewritten again.
With a rawhide-build ref (whether branch or tag) I can use a single
git command to tell that rawhide is ahead of rawhide-build, and I
immediately know that either there is a built happening now, or
rawhide is broken. At that point I can decide whether I want to try
and fix it, or contact the maintainer, or wait.
Maybe "rawhide-good" or "rawhide-built" would be a better name for the
ref than "rawhide-build".
_______________________________________________
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
