[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 <
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> 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
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190126/1cdf15f0/attachment.html>