On 03. 02. 21 14:08, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:
On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:
clime wrote:
So if some other maintainer pushes his work to the server meanwhile,
this will just delete his work? Or what's the idea here?
I guess the safe thing to do would be to wait and see whether that commit
also fails to build (i.e., if the CI build fails, check whether the built
commit is still the current HEAD, and trigger the revert only if it is,
otherwise defer the decision to the new HEAD's CI build), but if that is the
case, yes, it will definitely be deleted from the server. But it will still
be present in the maintainer's local checkout and can be trivially pushed
back together with a build fix.
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.
+1, this is much cleaner and simpler. Obviously, that branch would have
to have permissions to only allow pushes from CI.
Suddenly, you have a branch to which:
- maintainers push potentially broken content
- provenpackagers push their bumps
How is this better than status quo?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
