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
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
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.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devshttps://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.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devshttps://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