[GitLab] Introducing Marge-bot

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[GitLab] Introducing Marge-bot

Ben Gamari-3
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GitLab] Introducing Marge-bot

Matthew Pickering
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GitLab] Introducing Marge-bot

Phyx
> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [GitLab] Introducing Marge-bot

Ben Gamari-2
Phyx <[hidden email]> writes:

>> 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.
>
I tend to agree. If someone has commit rights then I generally trust
their judgement when it comes to trivial patches. That being said, we
should indeed offer more guidance regarding what constitutes "trivial".

We currently have a lack of reviewers and I don't want this lack to
become a reason why those contributors we do have might be driven
away.

Cheers,

- Ben



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [GitLab] Introducing Marge-bot

GHC - devs mailing list
In reply to this post by Phyx

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 <[hidden email]> On Behalf Of Phyx
Sent: 26 January 2019 19:43
To: Matthew Pickering <[hidden email]>
Cc: GHC developers <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs