<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 13 Mar 2017 at 09:48 Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="gmail_msg">
<br class="gmail_msg">
First, I'm really happy that we moved to git and GH.  The GH review tool<br class="gmail_msg">
is super convenient and CI integration helps.<br class="gmail_msg">
<br class="gmail_msg">
I'm less happy about requiring to make a PR for every commit. It's a no<br class="gmail_msg">
problem for new features development, but it's a huge pain for a bug<br class="gmail_msg">
fixing workflow.  Last week I needed to push a bunch of bug fixes to<br class="gmail_msg">
3.7/3.6/3.5.  I had about 6 pull requests to the master branch, + 12<br class="gmail_msg">
more for 3.6 and 3.5.  I basically killed my entire second half of the<br class="gmail_msg">
day waiting until CI checks clear out.  I spend a few hours pushing just<br class="gmail_msg">
3 (!!) committs to all branches.  Thanks to Brett, who disabled the push<br class="gmail_msg">
CI check for a while, I was able to push the remaining 3 bug fixes and<br class="gmail_msg">
their cherry picks in under 10 minutes.<br class="gmail_msg">
<br class="gmail_msg">
Yesterday I was working on a few asyncio PRs and a bug in async/await.<br class="gmail_msg">
All PRs required cherry-picking.  Again, I was spending significant<br class="gmail_msg">
amount of time just creating branches/PRs for cherry-picking.</blockquote><div><br></div><div>Were you creating the branches manually or using Mariatta's script?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Again<br class="gmail_msg">
waiting for CI checks (even though I always run the test suite before I<br class="gmail_msg">
push).  In the end of the day, I was so frustrated and discouraged that<br class="gmail_msg">
I just stopped working on CPython.<br class="gmail_msg"></blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
The current workflow makes it significantly harder for me to be<br class="gmail_msg">
productive.  At this point I'm so discouraged of working on any bug<br class="gmail_msg">
fixes that I consider to stop working on them until the full<br class="gmail_msg">
cherry-picking automation is implemented.<br class="gmail_msg">
<br class="gmail_msg">
So I guess what I'm asking for is to consider turning the CI/PR push<br class="gmail_msg">
requirement off until we have automatic cherry-picking and a new NEWS<br class="gmail_msg">
file workflow.  We lived without this check for many years with<br class="gmail_msg">
mercurial.  Yes, all of us pushed some broken commits, but we have<br class="gmail_msg">
buildbots and CI, so nothing horrible ever happended.<br class="gmail_msg"></blockquote><div><br></div><div>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. I had to tell people that it was already broken before their PR was submitted and once the fix was in that they needed to rebase to make sure their tests pass. And the only way to make this not be an issue without gating on CI is to require all PRs to be fully rebased before merging which is a constant merge race (which we all know from our forward merging days to be a massive pain and would then also require all PRs be merged through the command-line and never online in order to do the rebase for contributors who would always be behind).</div><div><br></div><div>IOW having CI is somewhat of an all-or-nothing thing here, else you are dealing with the fallout of a broken build for a while (compared to the Mercurial days where we all did the rebasing manually along with testing in order to avoid this issue). Now as Donald pointed out, our concurrency levels went up this morning so hopefully that will help with this.</div><div><br></div><div>It also doesn't help when randomness schedules test_tools, test_datetime, or test_tokenize towards the end of a test run since they all take a few minutes under clang (don't know why specifically clang, but there you go).</div><div><br></div><div>My point is that there are still some things we can do to make the turn-around time on CI to be faster: see if the slower tests could be sped up, deciding if we need all builds that we currently have, seeing if our new concurrency levels help, or even consider gating on AppVeyor instead of Travis. 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?</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Thank you,<br class="gmail_msg">
Yury<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On 2017-03-10 5:13 PM, Brett Cannon wrote:<br class="gmail_msg">
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday<br class="gmail_msg">
> when we moved. :)<br class="gmail_msg">
><br class="gmail_msg">
> First, I hope people are not regretting letting/having me make this<br class="gmail_msg">
> migration. I know there have been some things to work through (and<br class="gmail_msg">
> others still to come), but I hope this is all a net positive (either<br class="gmail_msg">
> now or in the near future).<br class="gmail_msg">
><br class="gmail_msg">
> Second, I wanted to get initial feedback on things we can easily tweak:<br class="gmail_msg">
><br class="gmail_msg">
>   * Requiring Travis to pass (I *really* don't want to turn this off<br class="gmail_msg">
>     as we already had a broken build when I temporarily turned it off<br class="gmail_msg">
>     at someone's request when Travis was backed up from the AWS S3<br class="gmail_msg">
>     outage; I also don't plan to make AppVeyor required unless there's<br class="gmail_msg">
>     a way to make it be skipped for doc-only changes)<br class="gmail_msg">
>   * Cherry-picking working out? (We can go back to forward merging if<br class="gmail_msg">
>     people really want to, but I think long-term cherry-picking will<br class="gmail_msg">
>     allow for more automation)<br class="gmail_msg">
>       o Along with that, are the labels for cherry-picking working<br class="gmail_msg">
>         out? (Some devs seem to like using title labels like `[3.6]`<br class="gmail_msg">
>         to flag cherry-picks so it's more obvious in emails so I don't<br class="gmail_msg">
>         know if the labels are really that useful)<br class="gmail_msg">
>   * Is the mention bot helpful? (Our config is at<br class="gmail_msg">
>     <a href="https://github.com/python/cpython/blob/master/.mention-bot" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/python/cpython/blob/master/.mention-bot</a> and the<br class="gmail_msg">
>     docs are at <a href="https://github.com/facebook/mention-bot" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/facebook/mention-bot</a>)<br class="gmail_msg">
>   * Anything to tweak about the coverage bot and reports? (Our config<br class="gmail_msg">
>     is at<br class="gmail_msg">
>     <a href="https://github.com/python/cpython/blob/master/.codecov.yml" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/python/cpython/blob/master/.codecov.yml</a> and<br class="gmail_msg">
>     docs at <a href="https://docs.codecov.io/docs/codecov-yaml" rel="noreferrer" class="gmail_msg" target="_blank">https://docs.codecov.io/docs/codecov-yaml</a>)<br class="gmail_msg">
><br class="gmail_msg">
> Third, I wanted to point out some of the more critical discussions<br class="gmail_msg">
> going on at <a href="https://github.com/python/core-workflow/issues" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/python/core-workflow/issues</a>.<br class="gmail_msg">
> Specifically, <a href="https://github.com/python/core-workflow/issues/6" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/python/core-workflow/issues/6</a> is<br class="gmail_msg">
> working towards a solution for Misc/NEWS so if you care about the<br class="gmail_msg">
> final solution you should participate there. After Misc/NEWS is solved<br class="gmail_msg">
> the next step becomes solving the cherry-picking overhead with a more<br class="gmail_msg">
> automated approach. We are also discussing closed branches to make the<br class="gmail_msg">
> list of branches more manageable at<br class="gmail_msg">
> <a href="https://github.com/python/core-workflow/issues/31" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/python/core-workflow/issues/31</a>.<br class="gmail_msg">
><br class="gmail_msg">
> Fourth, the lack of messages showing up on <a href="http://bugs.python.org" rel="noreferrer" class="gmail_msg" target="_blank">bugs.python.org</a><br class="gmail_msg">
> <<a href="http://bugs.python.org" rel="noreferrer" class="gmail_msg" target="_blank">http://bugs.python.org</a>> after a commit is being tracked at<br class="gmail_msg">
> <a href="http://psf.upfronthosting.co.za/roundup/meta/issue613" rel="noreferrer" class="gmail_msg" target="_blank">http://psf.upfronthosting.co.za/roundup/meta/issue613</a>. I'm sure Ezio<br class="gmail_msg">
> and Maciej would appreciate any help people may be able to volunteer<br class="gmail_msg">
> to help in solving the problem.<br class="gmail_msg">
><br class="gmail_msg">
> Fifth, anything I missed? :)<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> python-committers mailing list<br class="gmail_msg">
> <a href="mailto:python-committers@python.org" class="gmail_msg" target="_blank">python-committers@python.org</a><br class="gmail_msg">
> <a href="https://mail.python.org/mailman/listinfo/python-committers" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/python-committers</a><br class="gmail_msg">
> Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" class="gmail_msg" target="_blank">https://www.python.org/psf/codeofconduct/</a><br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
python-committers mailing list<br class="gmail_msg">
<a href="mailto:python-committers@python.org" class="gmail_msg" target="_blank">python-committers@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/python-committers" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/python-committers</a><br class="gmail_msg">
Code of Conduct: <a href="https://www.python.org/psf/codeofconduct/" rel="noreferrer" class="gmail_msg" target="_blank">https://www.python.org/psf/codeofconduct/</a><br class="gmail_msg">
</blockquote></div></div>