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