On Wed, 19 Jul 2017 at 08:18 R. David Murray wrote:
> On Tue, 18 Jul 2017 23:13:41 -, Brett Cannon wrote:
> > Do realize that setting is part of requiring a review for pull requests:
> >
> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
> .
> > So in order to ge
On Tue, 18 Jul 2017 23:13:41 -, Brett Cannon wrote:
> Do realize that setting is part of requiring a review for pull requests:
> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/.
> So in order to get this we would require all PRs, core dev or not, to
> receive an a
On 19 July 2017 at 09:37, Victor Stinner wrote:
> Oh.
>
> For backports, it's convenient to be able to merge without a review. I see
> many cores doing it and I like it.
>
> For master, I don't know. Sometimes a PR is merged too fast, sometiles
> nobody reviews a PR even if it's good. So for the m
On Tue, 18 Jul 2017 at 13:10 Victor Stinner
wrote:
> 2017-07-18 21:21 GMT+02:00 R. David Murray :
> > On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner <
> victor.stin...@gmail.com> wrote:
> >> I'm just not unconfortable with the fact that an approval is kept even
> >> if the PR is modified afte
Oh.
For backports, it's convenient to be able to merge without a review. I see
many cores doing it and I like it.
For master, I don't know. Sometimes a PR is merged too fast, sometiles
nobody reviews a PR even if it's good. So for the master branch, the dev
takes its own responsability to merge ;
2017-07-18 21:21 GMT+02:00 R. David Murray :
> On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner
> wrote:
>> I'm just not unconfortable with the fact that an approval is kept even
>> if the PR is modified after the review :-/ I would expect a list a
>> notice "changed modified after the review"
