[python-committers] 3.6 branch now open only for 3.6.0 release critical fixes and doc updates!

[Ned Deily]

On Nov 22, 2016, at 09:57, Victor Stinner <victor.stinner at gmail.com> wrote:
> 2016-11-22 8:24 GMT+01:00 Ned Deily <nad at python.org>:
>> OK, all of the release engineering for 3.6.0b4 is complete.  The 3.6 branch in the cpython repo is now available again but, as noted, *only* for reviewed release critical fixes appropriate for the 3.6.0 final and for final 3.6.0 doc updates!
> 
> Sorry, I pushed changes before reading your email(s). I expected that
> release critical changes would have to be pushed to a different
> repository using cherry-pick or something else.
> 
> To be clear: Python 3.5 will be frozen as well? Pushing to 3.5
> requires to merge into 3.6 (and then merge into default).

No, 3.5 is not necessarily frozen.  As I noted in yesterday's first email, you have two options:

"3. Hold off pushing changes that are not 3.6.0 release critical until after rc1 is tagged.  You can continue to push bug fixes as appropriate to other open branches if you are willing to back port them to the 3.6 branch, as necessary, after rc1 is tagged.  Or, if you prefer to follow the normal development flow, take a bugfix holiday for the next two weeks and just hold off pushing any changes that affect 3.6.1 until after rc1 is tagged.  With those (hopefully) small inconveniences to you, we won't have to go through a special Bitbucket PR process and it will ensure that our 3.6 buildbots continue to test what's going into 3.6.0."

In other words, if you as a committer feel comfortable with following a non-standard workflow during the current release candidate stage, you can certainly do so, i.e. pushing to 3.5 then merging to default and then, after the 3.6 branch is free again for 3.6.1, going back and backporting to 3.6.  Or, easier, just push to default for now and then backport to the 3.5 and 3.6 branches (and null merge to default) once 3.6 is free for 3.6.1 after rc1.  But, it probably is just easiest for most people to hold off pushing multiple branch changes until rc1 which should happen in two weeks.

Does that make sense?

> Four changes have been pushed after the tag:
> 
> (*) https://hg.python.org/cpython/rev/4f6fb9e47f6b
> Issue #28023: Fix python-gdb.py didn't support new dict implementation [#28023]
> 
> I reviewed Naoki's patch and it LGTM. python-gdb.py was simply 100%
> broken without this fix, and I consider that this tool is important
> for Python (but I didn't understood correctly the RC rules, sorry)! By
> the way, I also broke python-gdb.py with fast calls! I started to work
> on a fix, http://bugs.python.org/issue28770
> 
> 
> (*) https://hg.python.org/cpython/rev/9b974f988c95
> Issue #28023: Fix python-gdb.py on old GDB versions
> 
> ... My fix for the previous commit. Sadly, it's hard to test on all
> GDB versions, but buildbots are here for that :-)

I agree with Naoki and you that fixing python-gdb.py qualifies as release critical; it's also self-contained and thus low-risk.  Thanks for pushing and fixing that!

> (*) https://hg.python.org/cpython/rev/6b43d15fd2d7
> Issue #28727: Fix typo in pattern_richcompare()
> 
> Obvious bugfix spotted by Serhiy.

OK

> (*) https://hg.python.org/cpython/rev/c2cb70c97163de.
> Issue #28727: Optimize pattern_richcompare() for a==a
> 
> This one is a minor optimization suggested by Serhiy.

My feeling is that this change does not meet the Release Candidate criteria and I would not have pushed it myself.  But, now that it is there, I will leave it up to you and Serhiy to decide whether to revert it or not.  As long as it doesn't break anything, I'll be OK with either outcome.

Thanks for your help!

--Ned

--
  Ned Deily
  nad at python.org -- []