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