Re: [core-workflow] self-approving pull requests

I just checked the Travis CI status page, and it's showing a rather large backlog (~120-140 jobs) earlier today. Their site says: Our database provider has asked to make some changes to the existing primary logs DB that require we stop processing new jobs temporarily. They also mentioned that t

Re: [core-workflow] self-approving pull requests

> On Mar 3, 2017, at 5:53 PM, Tres Seaver wrote: > > Travis also throttles organizations with lots of builds. I’m seeing if I can get our default limit increased FWIW. — Donald Stufft ___ core-workflow mailing list core-workflow@python.org https

Re: [core-workflow] self-approving pull requests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/2017 07:51 PM, Brett Cannon wrote: > On Thu, 2 Mar 2017 at 16:16 Yury Selivanov > wrote: > >> >> >> On 2017-03-02 7:11 PM, Donald Stufft wrote: >>> I'm on my phone but unless Travis is backed up it sounds like >>> something >> got lost som

Re: [core-workflow] self-approving pull requests

On Thu, 2 Mar 2017 at 16:16 Yury Selivanov wrote: > > > On 2017-03-02 7:11 PM, Donald Stufft wrote: > > I'm on my phone but unless Travis is backed up it sounds like something > got lost somewhere. Multi hour waits is not typical. > > Travis is overloaded a little bit at the moment. It looks lik

Re: [core-workflow] self-approving pull requests

On 2017-03-02 7:06 PM, Brett Cannon wrote: The discussion of automating the creation of cherry-pick PRs is at https://github.com/python/core-workflow/issues/8. And the requirement of the PR is to force people to go through CI to verify the cherry-pick took cleanly (and the Travis config is stru

Re: [core-workflow] self-approving pull requests

On 2017-03-02 7:11 PM, Donald Stufft wrote: I'm on my phone but unless Travis is backed up it sounds like something got lost somewhere. Multi hour waits is not typical. Travis is overloaded a little bit at the moment. It looks like it takes it 20-30 minutes to fully test one PR. And it loo

Re: [core-workflow] self-approving pull requests

On 2017-03-02 7:01 PM, Donald Stufft wrote: Correct. Everything goes through a PR now. Ideally we will automate PRs for backports. Got it. Well, I guess my only complaint about this is that Travis is extremely slow. I've been waiting a couple of hours for my PR to pass the check (and it's

Re: [core-workflow] self-approving pull requests

The discussion of automating the creation of cherry-pick PRs is at https://github.com/python/core-workflow/issues/8. And the requirement of the PR is to force people to go through CI to verify the cherry-pick took cleanly (and the Travis config is structured to only run the test suite if the PR cha

Re: [core-workflow] self-approving pull requests

I'm on my phone but unless Travis is backed up it sounds like something got lost somewhere. Multi hour waits is not typical. Sent from my iPhone > On Mar 2, 2017, at 7:07 PM, Yury Selivanov wrote: > > Well, I guess my only complaint about this is that Travis is extremely slow. > I've been wa

Re: [core-workflow] self-approving pull requests

Correct. Everything goes through a PR now. Ideally we will automate PRs for backports. Sent from my iPhone > On Mar 2, 2017, at 7:00 PM, Yury Selivanov wrote: > > > >> On 2017-03-02 6:36 PM, Donald Stufft wrote: >> You no longer need approval from someone else and you can open a cherry-pick

Re: [core-workflow] self-approving pull requests

On 2017-03-02 6:36 PM, Donald Stufft wrote: You no longer need approval from someone else and you can open a cherry-pick PR prior to merging if you want. But I still can't push a cherry-picked commit without a PR for it? Yury ___ core-workflow mai

Re: [core-workflow] self-approving pull requests

One thing I forgot to mention is that cherry picking before a merge might result in more overall work if someone does review your original PR and it ends up causing changes since you'll need to pull those changes into each backport PR too. Sent from my iPhone > On Mar 2, 2017, at 6:44 PM, Yur

Re: [core-workflow] self-approving pull requests

On 2017-03-02 6:36 PM, Donald Stufft wrote: You no longer need approval from someone else and you can open a cherry-pick PR prior to merging if you want. OK, thanks for the clarification! Will try it later today. Thank you, Yury ___ core-workflow

Re: [core-workflow] self-approving pull requests

On 2017-03-02 6:40 PM, Senthil Kumaran wrote: Hi Yuri, On Thu, Mar 2, 2017 at 3:31 PM, Yury Selivanov wrote: I only started to use the new workflow today. And I think that the new rules are too restrictive. Enforcing checking and reviews and approvals is a right thing, but what we have now

Re: [core-workflow] self-approving pull requests

Hi Yuri, On Thu, Mar 2, 2017 at 3:31 PM, Yury Selivanov wrote: > I only started to use the new workflow today. And I think that the new rules > are too restrictive. Enforcing checking and reviews and approvals is a > right thing, but what we have now feels like too much. You are actually experi

Re: [core-workflow] self-approving pull requests

You no longer need approval from someone else and you can open a cherry-pick PR prior to merging if you want. Sent from my iPhone > On Mar 2, 2017, at 6:31 PM, Yury Selivanov wrote: > > I feel like a lot of bug fixes will have to be backported. With the > current rules I have to open a new PR

Re: [core-workflow] self-approving pull requests

I only started to use the new workflow today. And I think that the new rules are too restrictive. Enforcing checking and reviews and approvals is a right thing, but what we have now feels like too much. I feel like a lot of bug fixes will have to be backported. With the current rules I have to o

Re: [core-workflow] self-approving pull requests

On 25 February 2017 at 10:17, Brett Cannon wrote: > Two things. One, has someone verified that if a core dev edits a PR that > the squash commit still gives the PR creator the author credit in the git > metadata? I remember doing an edit like this once and GitHub didn't show > any author credit i

Re: [core-workflow] self-approving pull requests

Two things. One, has someone verified that if a core dev edits a PR that the squash commit still gives the PR creator the author credit in the git metadata? I remember doing an edit like this once and GitHub didn't show any author credit in the web UI because I assume GitHub refused to guess who th

Re: [core-workflow] self-approving pull requests

On 23 February 2017 at 05:26, Donald Stufft wrote: > You can clone their repository and make changes directly to their branch and > push to it I believe, assuming they allowed that when they made the PR. This is the part that GitHub hasn't documented very well from the maintainer side yet, but I

Re: [core-workflow] self-approving pull requests

> On Feb 22, 2017, at 11:17 PM, Nick Coghlan wrote: > > On 23 February 2017 at 02:25, Barry Warsaw wrote: >> On Feb 22, 2017, at 11:10 AM, Donald Stufft wrote: >> >>> FWIW, I don’t think that creating a new PR and closing the original one is a >>> subpar experience for contributors, particular

Re: [core-workflow] self-approving pull requests

On 23 February 2017 at 02:25, Barry Warsaw wrote: > On Feb 22, 2017, at 11:10 AM, Donald Stufft wrote: > >>FWIW, I don’t think that creating a new PR and closing the original one is a >>subpar experience for contributors, particularly if we turn off the bit that >>requires reviews and just turn on

Re: [core-workflow] self-approving pull requests

You can clone their repository and make changes directly to their branch and push to it I believe, assuming they allowed that when they made the PR. You should also be able to add their fork as a remote on your current branch using 'git remote add foobar githuburl' then checkout the got branch f

Re: [core-workflow] self-approving pull requests

On 02/22/2017 08:39 AM, Donald Stufft wrote: On Feb 22, 2017, at 11:25 AM, Barry Warsaw wrote: Since we're squashing commits wouldn't that obliterate the original author's credit for the work? Yes, github will credit the person who opened the PR, but the person who made the person who made

Re: [core-workflow] self-approving pull requests

> On Feb 22, 2017, at 11:25 AM, Barry Warsaw wrote: > > Since we're squashing commits wouldn't that obliterate the original author's > credit for the work? Yes, github will credit the person who opened the PR, but the person who made the person who made the PR can check the box (which I *beli

Re: [core-workflow] self-approving pull requests

On Feb 22, 2017, at 11:12 AM, Donald Stufft wrote: >I’m happy to switch this around, but I don’t know whose call it is. Does >Brett need to make this call? I dunno. Brett should at least get a chance to weigh in, so let's wait for him to return. -Barry pgpiq0BK6_x4D.pgp Description: OpenPGP di

Re: [core-workflow] self-approving pull requests

On Wed, Feb 22, 2017 at 8:12 AM, Donald Stufft wrote: > I’m happy to switch this around, but I don’t know whose call it is. Does > Brett need to make this call? I dunno. I am +1 on turning on the required status check before the merge is enabled. It was briefly discussed here: https://mail.python

Re: [core-workflow] self-approving pull requests

On Feb 22, 2017, at 11:10 AM, Donald Stufft wrote: >FWIW, I don’t think that creating a new PR and closing the original one is a >subpar experience for contributors, particularly if we turn off the bit that >requires reviews and just turn on the thing that requires passing >tests. Having been in t

Re: [core-workflow] self-approving pull requests

> On Feb 22, 2017, at 2:42 AM, Nick Coghlan wrote: > > I'm +1 for turning on required status checks though - giving us a > strong incentive to get the test suite stable and keep it that way is > an unequivocally good thing, and I do want to keep the "PR required, > even for core developers" expe

Re: [core-workflow] self-approving pull requests

> On Feb 22, 2017, at 10:22 AM, Nick Coghlan wrote: > > - attempt to amend the original PR (see > https://github.com/python/devguide/issues/129 > ). That may not work > depending on how the contributor has set up their fork and PR branch. > - crea

Re: [core-workflow] self-approving pull requests

On Wed, Feb 22, 2017 at 4:22 PM, Nick Coghlan wrote: > On 18 February 2017 at 09:24, Donald Stufft wrote: > > We turned on require code review for the PR, though at the time I > *thought* > > it still allowed you to approve your own PR. Apparently that was wrong. > > Brett was the one to actuall

Re: [core-workflow] self-approving pull requests

On 18 February 2017 at 09:24, Donald Stufft wrote: > We turned on require code review for the PR, though at the time I *thought* > it still allowed you to approve your own PR. Apparently that was wrong. > Brett was the one to actually make the decision to do it and turned it on, > so I don’t know

Re: [core-workflow] self-approving pull requests

On Wed, Feb 22, 2017 at 8:51 AM, Nick Coghlan wrote: > On 22 February 2017 at 13:12, Nick Coghlan wrote: > > I'm +1 for turning on required status checks though - giving us a > > strong incentive to get the test suite stable and keep it that way is > > an unequivocally good thing, and I do want

Re: [core-workflow] self-approving pull requests

On 18 February 2017 at 05:12, Senthil Kumaran wrote: > On Fri, Feb 17, 2017 at 3:32 PM, Barry Warsaw wrote: >> As you say, reviewer bandwidth is a bottleneck > > Would anyone consider "Requiring a review from another > core-developer" is actually a helpful thing? No, because we don't have anyth

Re: [core-workflow] self-approving pull requests

On 22 February 2017 at 13:12, Nick Coghlan wrote: > I'm +1 for turning on required status checks though - giving us a > strong incentive to get the test suite stable and keep it that way is > an unequivocally good thing, and I do want to keep the "PR required, > even for core developers" experimen

Re: [core-workflow] self-approving pull requests

On Feb 17, 2017, at 03:45 PM, Senthil Kumaran wrote: >On Fri, Feb 17, 2017 at 2:39 PM, Barry Warsaw > wrote: >> >> But now I'm stuck and I'm impatient. ;) > >No more. :) Thanks Senthil! And thanks Berker who also reviewed the branch. >I spent time reading the bug, understanding the comments,

Re: [core-workflow] self-approving pull requests

https://github.com/python/core-workflow/issues/32 might help as well. Sent from my iPhone > On Feb 17, 2017, at 6:32 PM, Barry Warsaw wrote: > > As you say, reviewer bandwidth is a bottleneck (something that I'm personally > going to try to help with now that we're on GH), so at least for now,

Re: [core-workflow] self-approving pull requests

On Fri, Feb 17, 2017 at 2:39 PM, Barry Warsaw wrote: > > But now I'm stuck and I'm impatient. ;) No more. :) I spent time reading the bug, understanding the comments, reviewing the code, and then toggled my approval. The later action was a helpful thing for "me", in addition to being helpful to

Re: [core-workflow] self-approving pull requests

On Fri, Feb 17, 2017 at 2:39 PM, Barry Warsaw wrote: > > But now I'm stuck and I'm impatient. ;) No more. :) I spent time reading the bug, understanding the comments, reviewing the code, and then toggled my approval. The later action was a helpful thing for "me", in addition to being helpful to

Re: [core-workflow] self-approving pull requests

On Fri, Feb 17, 2017 at 3:32 PM, Barry Warsaw wrote: > As you say, reviewer bandwidth is a bottleneck Would anyone consider "Requiring a review from another core-developer" is actually a helpful thing? The positives I see are: 1) Forcing other developers with commit rights to act soon and revi

Re: [core-workflow] self-approving pull requests

On Feb 17, 2017, at 06:24 PM, Donald Stufft wrote: >2) Turn it off, but turn on requiring status checks which will still >effectively require a PR (there is one way around this, but it is so >convoluted nobody would be able to do it by accident, and things still get >tested anyways). I do like re

Re: [core-workflow] self-approving pull requests

We turned on require code review for the PR, though at the time I *thought* it still allowed you to approve your own PR. Apparently that was wrong. Brett was the one to actually make the decision to do it and turned it on, so I don’t know if he knew that it didn’t allow people to self-approve or

[core-workflow] self-approving pull requests

I submitted PR#138 on bpo-22807. I got a nice review from a community member and made a small change. All checks have passed. But now I'm stuck and I'm impatient. ;) The change is small enough and I'm happy with it, and I could patiently wait for another core dev to approve it, but in the likel