On Jul 3, 2017, at 5:45 AM, Evilham <contact@evilham.com> wrote:



Am 03/07/2017 um 14:24 schrieb Evilham:
Hi Glyph,

Am 03/07/2017 um 14:08 schrieb Glyph:
Unfortunately, our CI runs can be quite lengthy.  When doing a quick code review, it can often be quite demoralizing to see an hour or two worth of appveyor backlog that needs to run before a ticket can be merged.

I have been thinking about adding a specific "OK to merge" label to PRs that indicates that they've been submitted to pr_as_branch, they've been reviewed, and if the CI results or positive they should be merged, so that someone other than the reviewer might come along and do the actual merge later.  Does anyone else think this would be a good idea?

Isn't this exactly what you want Glyph? (maybe I missed sth :-D)
https://help.github.com/articles/about-required-reviews-for-pull-requests/

No, this just prevents you from merging if you don't have a review; it doesn't automatically merge if you do have one.


It could affect the workflow of people with write-access though.

If those are GitHub labels and only modifiable by repo owners, it sounds
like a sane thing to do.

One thing that would worry me though, is that more commits could come to
that PR after the reviewer (repo owner) sets the 'OK to merge' tag, I
guess such a tag should be associated with the last commit but I'm not
too sure that's possible out of the box with GitHub.

(I know that there are ways that bots can facilitate this, and if someone else would like to set that up, that would be great.)

Maybe a bot could figure out the last reviewed commit and remove the
label if it detects new (not reviewed) commits in that PR.

I... would actually be interested in taking a look at it, got any
pointers / are there already some bots for the twisted project running?


--
Evilham

_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python