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!