> 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 < matthewtpicker...@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 <b...@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@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs