From yselivanov.ml at gmail.com Thu Mar 2 18:31:53 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 2 Mar 2017 18:31:53 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <20170217173915.2c9f3fdd@subdivisions.wooz.org> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> Message-ID: 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 open a new PR and ask someones approval *and* wait until Travis completes the build before I can cherry-pick and push. I like GH, git, and all other tools we now have. But current workflow needs to be loosen up a little IMHO. Yury On 2017-02-17 5:39 PM, Barry Warsaw wrote: > 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 likely case that no one else is > interested in the bug, I'd like to be able to self-approve and accept it. > This of course is described as my right in the devguide, along with the > responsibility to watch the buildbots and revert the change if there are any > problems with it. > > But it seems like I cannot do that through the GH UI. Right now I'm seeing > > (X) Review required > (?) All checks have passed > (X) Merge is blocked > > There seems to be no way to self-approve the PR. If I go to 'Files changed' > tab and click on 'Review changes', both Approve and Request changes is > dimmed. I can only comment on my own PR. > > I can understand why we might want to prohibit self-approvals, but that's also > a regression in the permissions and rights of core developers. I also think > it's counterproductive since without that I might have to go begging for a > review approval before the branch can land. > > Is this intentional or an oversight? > > (As an owner of the project, I took a quick look at the project settings and > couldn't find a control for this, but I know other GH projects I contribute to > support self-approval.) > > Cheers, > -Barry > > > > _______________________________________________ > core-workflow mailing list > core-workflow at python.org > https://mail.python.org/mailman/listinfo/core-workflow > This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct From donald at stufft.io Thu Mar 2 18:36:09 2017 From: donald at stufft.io (Donald Stufft) Date: Thu, 2 Mar 2017 18:36:09 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> Message-ID: <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> 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 and ask someones approval *and* > wait until Travis completes the build before I can cherry-pick and push. From senthil at uthcode.com Thu Mar 2 18:40:42 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 2 Mar 2017 15:40:42 -0800 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> Message-ID: 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 experiencing an "improved" process since it was more more restrictive 7 days ago. So, you could actually describe what you felt was cumbersome with this "new" process and perhaps that could be tackled next. -- Senthil From yselivanov.ml at gmail.com Thu Mar 2 18:44:00 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 2 Mar 2017 18:44:00 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> Message-ID: <2d166120-d331-953a-484f-e8b71bcfeda1@gmail.com> 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 feels like too much. > You are actually experiencing an "improved" process since it was more > more restrictive 7 days ago. > So, you could actually describe what you felt was cumbersome with this > "new" process and perhaps that could be tackled next. > Thank you Senthil. Donald already clarified that my concerns about pushing cherry-picks have been already addressed. I'm going to be pushing some changes today, and will report if something comes up. Thanks, Yury From yselivanov.ml at gmail.com Thu Mar 2 18:40:56 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 2 Mar 2017 18:40:56 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> Message-ID: <102f7188-1645-6099-0ddd-b0e575df2443@gmail.com> 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 From donald at stufft.io Thu Mar 2 18:52:42 2017 From: donald at stufft.io (Donald Stufft) Date: Thu, 2 Mar 2017 18:52:42 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <2d166120-d331-953a-484f-e8b71bcfeda1@gmail.com> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <2d166120-d331-953a-484f-e8b71bcfeda1@gmail.com> Message-ID: <2080A4BB-BF82-4A84-9E61-0EE1D3D01A8D@stufft.io> 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, Yury Selivanov wrote: > > Donald already clarified that my > concerns about pushing cherry-picks have been already > addressed. From yselivanov.ml at gmail.com Thu Mar 2 19:00:27 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 2 Mar 2017 19:00:27 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> Message-ID: 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 From donald at stufft.io Thu Mar 2 19:01:49 2017 From: donald at stufft.io (Donald Stufft) Date: Thu, 2 Mar 2017 19:01:49 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> Message-ID: <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> 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 PR prior to merging if you want. > > But I still can't push a cherry-picked commit without a PR for it? > > Yury From donald at stufft.io Thu Mar 2 19:11:43 2017 From: donald at stufft.io (Donald Stufft) Date: Thu, 2 Mar 2017 19:11:43 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> Message-ID: 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 waiting a couple of hours for my PR to pass the check (and it's not yet done). From yselivanov.ml at gmail.com Thu Mar 2 19:13:33 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 2 Mar 2017 19:13:33 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> Message-ID: <3a2a2356-74b8-d21b-fe91-a27b90360709@gmail.com> 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 looks like it tests PRs one by one, so if you have many PRs in the queue it takes it a while to go through all of them. Yury From brett at python.org Thu Mar 2 19:06:35 2017 From: brett at python.org (Brett Cannon) Date: Fri, 03 Mar 2017 00:06:35 +0000 Subject: [core-workflow] self-approving pull requests In-Reply-To: <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> Message-ID: 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 changes things outside of Doc/; same goes for building the docs and code coverage is never waited on). On Thu, 2 Mar 2017 at 16:02 Donald Stufft wrote: > 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 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 mailing list > core-workflow at python.org > https://mail.python.org/mailman/listinfo/core-workflow > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yselivanov.ml at gmail.com Thu Mar 2 19:07:02 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 2 Mar 2017 19:07:02 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> Message-ID: 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 not yet done). When Travis is green, I'll push commits to master, create new PRs for cherry-picks and will have to wait another 1-2-N hours until I can push them. With old workflow we trusted core devs to run full test suite locally, and while buildbots were failing sometimes it wasn't a very frequent case. Yury From yselivanov.ml at gmail.com Thu Mar 2 19:21:59 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 2 Mar 2017 19:21:59 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> Message-ID: <3901d87e-8d80-8993-85d9-6ee9aeefd005@gmail.com> 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 structured to only run the test suite if > the PR changes things outside of Doc/; same goes for building the docs and > code coverage is never waited on). The issue here is that we now don't seem to trust core devs to check if cherry-picks are good and working. In an ideal world where online tooling spends as much time as running the test suite locally it would work flawlessly. In the reality, it simply takes a lot of time *waiting* and is quite distracting. Anyways, this is just my 2 cents. Maybe I just need more time to get accustomed to the new process. Thanks, Yury From brett at python.org Thu Mar 2 19:51:48 2017 From: brett at python.org (Brett Cannon) Date: Fri, 03 Mar 2017 00:51:48 +0000 Subject: [core-workflow] self-approving pull requests In-Reply-To: <3a2a2356-74b8-d21b-fe91-a27b90360709@gmail.com> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> <3a2a2356-74b8-d21b-fe91-a27b90360709@gmail.com> Message-ID: 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 like it takes > it 20-30 minutes to fully test one PR. And it looks like it tests PRs > one by one, so if you have many PRs in the queue it takes it a while to > go through all of them. > Yeah, something is going on with Travis as it should typically only take 30 minutes. It might be due to backup they have from the S3 outage yesterday. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tseaver at palladion.com Fri Mar 3 17:53:40 2017 From: tseaver at palladion.com (Tres Seaver) Date: Fri, 3 Mar 2017 17:53:40 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> <3a2a2356-74b8-d21b-fe91-a27b90360709@gmail.com> Message-ID: -----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 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 looks like it >> tests PRs one by one, so if you have many PRs in the queue it takes >> it a while to go through all of them. >> > > Yeah, something is going on with Travis as it should typically only > take 30 minutes. It might be due to backup they have from the S3 > outage yesterday. Travis also throttles organizations with lots of builds. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJYufPvAAoJEPKpaDSJE9HYSJAP/0tkNd2CiA2zECc91v5D2+7w 32ZgLOPmq4uBQRbkHVUTpi9hll5BzGX4CsQCoy03V2MJz/YU9styHN8s9NC0ugfq BcQn5xGVCr2ZploAeCfaSNe1pG6PjnnFmege9vc2Q2cgrft65SsIHKs3Vngws56X KHupE4/cNLApLVBrYO/O8rbP7rFhm35sGzpaRl2MUY86DuBp0PK6p8wgNkIY3mkl u3LQiCwILuPxzVtWgbEZUO3GtHpbI0AM+DOdQ/82qCVGRWVmN3woopJsdVKMKtvH /VldxKARpVjQcaVKJ3ERayNOlrQS2AssoGQ5PV9QmJxYy1ZZL9ni6fwfBpFKR3RY Zi2jbGloyy0fZmmDHWtV4E9ThULgVOExXbp4sWxqSx9g4ZmH0aKxewVLMrzV+GCT dbRyHSDuYC0tEKWzvp6v8E5/M30623iN9GARN3+lc9WmQ8MN0iPvM99vOs1hj5wD 894/UTMw/l/YV4bfcSsc8UpYxfw7q6qedXYYtRULy01Qw1X7aAbz/nPRj++mAOtP +RxkTgGFm0PmrBPLYVpT8vuJHMMH9mskBoBGa8pDMHSMCfVIg/aBPuXMQDc9Juso bj6mLY907y0xObSZ3tauzGDkTvig9jCfcKlqTjjjKRDLvil+9efZoZTvXDVOZpyU WbEITgoPjYSOGscxyWOp =GazO -----END PGP SIGNATURE----- From donald at stufft.io Fri Mar 3 17:54:32 2017 From: donald at stufft.io (Donald Stufft) Date: Fri, 3 Mar 2017 17:54:32 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> <3a2a2356-74b8-d21b-fe91-a27b90360709@gmail.com> Message-ID: > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Fri Mar 3 20:05:37 2017 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 3 Mar 2017 19:05:37 -0600 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <0A5A075F-C995-437F-B8CE-5BBFF4C19779@stufft.io> <1A234238-EE7D-4DA6-BA01-E4EE159ACA1F@stufft.io> <3a2a2356-74b8-d21b-fe91-a27b90360709@gmail.com> Message-ID: 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 the S3 issue was causing them trouble, too, and they ALSO had a short API outage. I'm maybe it was just really bad luck that caused a bit of a backlog? AFAIK OSS projects are supposed to get up to 5 builds running concurrently. Maybe it would be worthwhile to attempt to parallel-ize the tests that don't depend on each other in any way? Also, this has nothing to do with this post, but when I saw this email, GMail showed the senders as "Barry .. Tres, Donald", and I thought it said "Trump, Donald". On Fri, Mar 3, 2017 at 4:54 PM, Donald Stufft wrote: > > 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 at python.org > https://mail.python.org/mailman/listinfo/core-workflow > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct > -- Ryan (????) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Mar 17 14:27:24 2017 From: brett at python.org (Brett Cannon) Date: Fri, 17 Mar 2017 18:27:24 +0000 Subject: [core-workflow] My new, asynchronous GitHub library Message-ID: Since people have been discussing writing various bots to help automate the workflow, I thought I should let this list know that I have created https://github.com/brettcannon/gidgethub. Specifically this is a GItHub library that is asynchronous from the bottom-up so there won't be any scaling issues with any bot. It also tries to not be too clever for its own good -- although it does currently pause your requests if you exhaust your API quota -- so that if you want to use some new API from GitHub you don't have to wait for me to update the library. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Mar 17 17:20:26 2017 From: brett at python.org (Brett Cannon) Date: Fri, 17 Mar 2017 21:20:26 +0000 Subject: [core-workflow] Working towards a decision on Misc/NEWS Message-ID: https://github.com/python/core-workflow/issues/6#issuecomment-287472168 We have three tools in the running: towncrier from Twisted, reno from OpenStack, and blurb from Larry Hastings. We have PRs containing example output for each tool for people to look at to see what the input and output will look like. Over the next week I will be collecting feedback from people before making a decision of which tool to go with. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Tue Mar 28 10:39:36 2017 From: rdmurray at bitdance.com (R. David Murray) Date: Tue, 28 Mar 2017 10:39:36 -0400 Subject: [core-workflow] "backport needed" status Message-ID: <20170328143936.56DFD1310015@webabinitio.net> If there is objection I will happily revert it, but I needed to mark an issue on bugs.python.org as still needing backport, since I'd merged the fix and the PR is now closed but I have no time currently to learn about how to do backports(*). So I added a 'backport needed' status to the tracker. I there is agreement that this is a good idea and should remain, we can maybe get rid of it later after backports are automated. But I have a feeling we'll want it long term, given the new workflow and the fact that not all backports can be done automatically. --David (*) Or, to be more accurate, I'm waiting until you all figure out how to automate it. From brett at python.org Tue Mar 28 13:37:21 2017 From: brett at python.org (Brett Cannon) Date: Tue, 28 Mar 2017 17:37:21 +0000 Subject: [core-workflow] "backport needed" status In-Reply-To: <20170328143936.56DFD1310015@webabinitio.net> References: <20170328143936.56DFD1310015@webabinitio.net> Message-ID: On Tue, 28 Mar 2017 at 07:39 R. David Murray wrote: > If there is objection I will happily revert it, but I needed to mark an > issue on bugs.python.org as still needing backport, since I'd merged > the fix and the PR is now closed but I have no time currently to learn > about how to do backports(*). So I added a 'backport needed' status > to the tracker. > > I there is agreement that this is a good idea and should remain, we can > maybe get rid of it later after backports are automated. But I > have a feeling we'll want it long term, given the new workflow > and the fact that not all backports can be done automatically. > I'm fine with it personally. I have had a couple of instances where I wanted to merge something but I didn't want to lose track of the fact that I had some cherry-picking to do, so I waited until I got home. WIth this flag I can just assign the issue to myself as a reminder and then do the merge immediately while still doing the cherry-picking when I get home. > > --David > > (*) Or, to be more accurate, I'm waiting until you all figure out how > to automate it. > :) https://github.com/python/core-workflow/tree/master/cherry_picker actually automates a lot of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Mar 31 19:23:58 2017 From: brett at python.org (Brett Cannon) Date: Fri, 31 Mar 2017 23:23:58 +0000 Subject: [core-workflow] Starting a bot to identify issues with PRs Message-ID: I have created a bot that I hope we can use to host all non-CLA checks for a PR that isn't covered by CI: https://github.com/brettcannon/bedevere. To start, the bot would check for a bugs.python.org issue number and set a failing status if one isn't found, else link the status to the issue itself. If the approach I took in the bot seems reasonable to people I will add support for a "trivial" label which would cause the bot to say the check is successful due to the fact that the PR is trivial enough to not warrant an issue to begin with. We can then continue to expand this bot to do other things like check that there is a NEWS file (unless marked as "trivial"). I don't want to role the CLA bot into bedevere since I created the bot in such a way as to be useful to other organizations on GitHub. So the Knights Who Say Ni will stay a separate repo. -------------- next part -------------- An HTML attachment was scrubbed... URL: