lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new procedure with GitLab CI


From: David Kastrup
Subject: Re: new procedure with GitLab CI
Date: Thu, 28 May 2020 03:03:48 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dan Eble <dan@faithful.be> writes:

> On May 27, 2020, at 07:16, David Kastrup <dak@gnu.org> wrote:
>> 
>> Now that we have the first "please get in line" merge that isn't
>> actually to any degree unusual, I get the suspicion that my previous
>> alternative proposal of pushing to a CI-less staging branch that then
>> uses CI to get to master will eventually become a reality.
>
> I wasn't much bothered by this round of merging.
>
> I wonder how the rest of you feel about having another developer click
> the buttons to rebase and merge your MRs?

If you refer to me doing that on Han-Wen's merge request, he actually
started his pipeline (with merge-to-master-when-finished) shortly after
mine and it ended up not being allowed to push because of requiring a
rebase after my merge request went through.  So when I saw that I caused
his intended merge to fail (or rather, that he had not checked whether
my earlier started pipeline was a merging one), I restarted his pipeline
as a "courtesy" since the rebase was a trivial one.  So it's not as much
that I as "another developer clicked the buttons to rebase and merge his
MRs" rather than that I forced GitLab to complete his explicit order.

For a trivial rebase, I don't see much wrong here but of course others
may see this as taking too much of a liberty here.

> Maybe we could adopt a convention that if you would object to that,
> you configure your MR so that you are the only one who is allowed to
> merge; and if you don't do that, then anyone who comes by at a time no
> pipelines are running would be free to start one.  — Dan

I don't think it would be a good idea to start a pipeline on somebody
else's merge request without having an indication that they were going
to follow through with "Patch_push": Patch_push indicates no objections
from foreign review, but the responsibility for starting the final
pipeline/merge should really lie with the original submitter.

In this case, Han-Wen already made the decision but GitLab did not
complete it.  And the patched area was not related to mine, either.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]