Re: [python-committers] 4 weeks with the new workflow: what needs changing?
On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon wrote: > > > On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg wrote: >> >> On 10.03.2017 23:13, Brett Cannon wrote: >> > Fifth, anything I missed? :) >> >> My main nit after the move is that messages to the checkin list >> no longer include the full patch. This makes reviews harder than >> necessary (you always have to go through the browser). >> >> Is there some way this could be changed back to what we had >> previously or is this a hard limitation of github ? > > > It's a hard limitation of the GitHub-provided email solution. With GitHub's > APIs and enough time someone could either come up with a custom email > solution or a web page that showed this information (you literally just need > to add ".diff" to the end of a URL to get the diff itself for a PR, e.g. > https://github.com/python/cpython/pull/648.diff will redirect to a raw > diff). There might also already be other solutions out there that do what > you're after. > > Obviously this all requires work on someone's part. :) (I've also moved > completely off of an email-based workflow so I'm definitely not the right > person to drive this sort of thing.) I wrote https://github.com/berkerpeksag/cpython-emailer-webhook to solve this problem. It works and its output is almost same as the old one [1] I even wrote some tests and documentation, but I just noticed that I forgot to push to GitHub :) If we all agree on the idea I can help with deploying it. I can use my own VPS for the initial deploy, but it would be nice to have a PSF backed server in the long term. --Berker [1] https://github.com/python/core-workflow/issues/24#issuecomment-279162079 ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] cherry_picker.py is now in core-workflow repo
Hi, I imported my cherry picker script into https://github.com/ python/core-workflow/tree/master/cherry_picker/ Please try it out if you need to do backports for CPython. It still needs some improvement with handling merge conflict, but if you don't anticipate any conflict then it should make things easy for you. (things that do not involve Misc/NEWS, for example) After the migration, I used it to cherry-pick this PR: https://github.com/python/cpython/pull/670 can confirm it works. Thanks Nick Coghlan who has started using and contributing to it too :) I believe he has a PR coming soon that adds a --dry-run option, which I look forward to :) Mariatta Wijaya ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 4 weeks with the new workflow: what needs changing?
On Wed, 15 Mar 2017 at 08:44 Berker Peksağ wrote: > On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon wrote: > > > > > > On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg wrote: > >> > >> On 10.03.2017 23:13, Brett Cannon wrote: > >> > Fifth, anything I missed? :) > >> > >> My main nit after the move is that messages to the checkin list > >> no longer include the full patch. This makes reviews harder than > >> necessary (you always have to go through the browser). > >> > >> Is there some way this could be changed back to what we had > >> previously or is this a hard limitation of github ? > > > > > > It's a hard limitation of the GitHub-provided email solution. With > GitHub's > > APIs and enough time someone could either come up with a custom email > > solution or a web page that showed this information (you literally just > need > > to add ".diff" to the end of a URL to get the diff itself for a PR, e.g. > > https://github.com/python/cpython/pull/648.diff will redirect to a raw > > diff). There might also already be other solutions out there that do what > > you're after. > > > > Obviously this all requires work on someone's part. :) (I've also moved > > completely off of an email-based workflow so I'm definitely not the right > > person to drive this sort of thing.) > > I wrote https://github.com/berkerpeksag/cpython-emailer-webhook to > solve this problem. It works and its output is almost same as the old > one [1] I even wrote some tests and documentation, but I just noticed > that I forgot to push to GitHub :) > > If we all agree on the idea I can help with deploying it. I can use my > own VPS for the initial deploy, but it would be nice to have a PSF > backed server in the long term. > I believe we have free Heroku resources to putting it there should be easy (the infrastructure team would know best obviously where we have free resources). -Brett > > --Berker > > [1] > https://github.com/python/core-workflow/issues/24#issuecomment-279162079 > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 4 weeks with the new workflow: what needs changing?
On Tue, 14 Mar 2017 at 16:26 Barry Warsaw wrote: > On Mar 14, 2017, at 06:16 PM, Ned Deily wrote: > > >There is one pattern that is happening fairly often and that I think we > >should do something about. That is, non-committers submitting a PR > without > >first opening an issue on BPO. It gets very old fast trying to enforce > that. > >Perhaps one of the bots could flag PRs that do not have a BPO ref in their > >titles? > > Should there be a way to override that? In another project of mine on GH, > we > use a 'trivial' tag on the PR to bypass that check. > But that would require that external contributors know to set that label ahead of time and I'm willing to bet most won't. I see two ways of solving this. One is to have a bot that leaves a comment when an issue isn't seen, otherwise it leaves a comment with a link back to the original issue for easy access. The other is we add a PR template that mentions that the title should include a reference to the issue for anything but the most trivial PR (and to create an issue otherwise).Obviously there's a great variance in effort required but also with the usefulness of what the solution does. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 4 weeks with the new workflow: what needs changing?
On Mar 16, 2017, at 12:00 AM, Brett Cannon wrote: >But that would require that external contributors know to set that label >ahead of time and I'm willing to bet most won't. Not if the test has a retry feature. Your change is trivial but you didn't add the label. The test fails. You add the label and retry the test. Now it passes. -Barry pgpemjhCBMZFe.pgp Description: OpenPGP digital signature ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 4 weeks with the new workflow: what needs changing?
Hi Brett, On 2017-03-14 6:00 PM, Brett Cannon wrote: [..] Yesterday I was working on a few asyncio PRs and a bug in async/await. All PRs required cherry-picking. Again, I was spending significant amount of time just creating branches/PRs for cherry-picking. Were you creating the branches manually or using Mariatta's script? I'll check it out! Again waiting for CI checks (even though I always run the test suite before I push). In the end of the day, I was so frustrated and discouraged that I just stopped working on CPython. Our Travis runs just got increased today so this should be improved. As I have also previously said we can consider scaling back the number of things we're building if necessary (i.e. we could go as low as 3 instead of the 5 we currently have or trying building using g++ to combine gcc and the C++ header check). Yeah, reducing the number of tasks would really help. Anything that can make required CI checks quicker. It's a double-edged sword when you don't gate on CI but you have it for all PRs. When Serhiy accidentally broke the build when I turned off Travis gating for you, all PRs for a few hours came in as failing and it confused some external contributors as to why their PR was coming up red. Ah, OK, I now better understand the rationale for requiring CI pass. [..] If all of those things are tried and we are still seeing unacceptably long wait times on PRs, then we can talk about turning off the CI gating. Does that seem fair? It's not just long waiting times (although it's a huge factor), it's that you have to create temporary branches for cherry-picks. With scripts or without, it's a lot of bookkeeping. Also, interacting with a console is still much more convenient than using web tools (at least for me). Anyways, while I don't totally enjoy the current workflow I see why it is as it is right now. I'll try to get used to it. Thank you, Yury P.S. Thanks to everybody who's been working on GH migration. Overall it's a very positive change! ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 4 weeks with the new workflow: what needs changing?
On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov wrote: > It's not just long waiting times (although it's a huge factor), it's > that you have to create temporary branches for cherry-picks. With > scripts or without, it's a lot of bookkeeping. Also, interacting with a > console is still much more convenient than using web tools (at least for > me). +100 :) --David ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
