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.
Regards,
Dominik
--
Fedora
https://getfedora.org | RPM Fusion
http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan