[GitLab] Introducing Marge-bot

[Simon Peyton Jones]

I rather agree with Tamar here.

Not everyone can press the “commit to master” button.  (They were previously called “people with commit rights” but now I’m not sure what the appropriate name is.)  For those who do have such access, I think we should trust them to pull the trigger only when appropriate.  Yes, there will be errors of judgement sometimes – I have been guilty of such myself – but particularly with our new CI checks, these errors seldom harm others for long, and can be corrected by a subsequent commit.

By contrast, the frustration that Tamar describes can be quite demoralising, when (entirely without anyone intending this to happen) some small commit is unreasonably delayed.

We rely very strongly on people’s willingness to contribute, and should strive at every opportunity to remove barriers to doing so.   I suggest we just trust people’s judgement, backed by a CI validatation check.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Phyx
Sent: 26 January 2019 19:43
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: GHC developers <ghc-devs at haskell.org>
Subject: Re: [GitLab] Introducing Marge-bot

> I also don't think one should be allowed to approve their own
> PR. If it is trivial enough to justify a self-accept then someone else
> should also be able to trivially accept it.

I disagree whole heartedly, as someone who's had to wait weeks for trivial patches to get reviews no thanks.
We should have a  formal definition of what is allowed to get committed as trivial much like a lot of open source
projects do and go from there.

I prefer a practical workflow, not just one that works for areas of the compiler where you have many people working,
It's a very frustrating experience otherwise.

Tamar.

On Wed, Jan 23, 2019 at 9:29 AM Matthew Pickering <matthewtpickering at gmail.com<mailto:matthewtpickering at gmail.com>> wrote:
It seems that in order for marge-bot to work best we need to
tighten up our policy towards merging so that it is only Marge
who performs the merges. I think Marge gets confused if people
push to master under her feet which means rebasing again and duplicating work.

Can we disable the "Merge when pipeline succeeds button" in order to
facilitate this?

I also don't think one should be allowed to approve their own
PR. If it is trivial enough to justify a self-accept then someone else
should also be able to trivially accept it.

Therefore I believe the correct workflow is:

1. Make a MR and assign it to someone if you want their specific review.
2. When the MR has been approved, the approver assigns the MR to marge.
3. Marge then performs the merge in her own time.

Cheers,

Matt

On Tue, Jan 22, 2019 at 8:31 PM Ben Gamari <ben at well-typed.com<mailto:ben at well-typed.com>> wrote:
>
> Hi everyone,
>
> As you might have noticed there is a new face on GitLab: Meet
> @marge-bot.
>
> Marge will be helping us with the pain of merging merge requests:
> Currently the typical workflow to merge an accepted MR involves the
> following:
>
>  1. Rebase the MR on top of the current `master` branch
>  2. Click on the "Merge when pipeline succeeds" button
>  3. Wait.
>  4. If another MR is merged before yours, return to step (1)
>
> Given the volume of patches that we have, this process gets tiresome
> quite quickly. Upstream knows [1] about this issue and is actively
> working towards a solution which will likely be ready in a few months.
>
> In the meantime, Marge automates this currently-manual process. With
> Marge merging a patch involves just two steps:
>
>  1. Ensure that the MR has at least one approval. This should happen in
>     the course of normal review but ping @bgamari, @alpmestan, @osa1, or
>     @tdammers if this was forgotten.
>
>  2. Use the "Assignee" field in the sidebar on the right side of the MR
>     to assign it to @marge-bot.
>
> Once Marge notices your MR she will dutifully watch over it, rebasing it
> as necessary until it is merged. If something goes awry, she will leave
> a (hopefully) helpful message and assign the MR back to you.
>
> So far Marge has been working out reasonably well and seems to be an
> improvement over the status quo. However, she still has some quirks so
> let me know if you think she is behaving erratically or otherwise have
> questions.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4c02ffbc7084916e7e208d683c68d08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636841286138065701&sdata=ybQClPJNmWzmiD3Yur5VyfjN%2BCTNWtMDR1%2F928aUn60%3D&reserved=0>
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4c02ffbc7084916e7e208d683c68d08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636841286138075705&sdata=sJcidhcUoDS2pdvvCM7OXebzN7Bz2j9Sj3PpgAIoZcg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190128/3a5eca8a/attachment.html>