[Python-Dev] Freeze exception for http://bugs.python.org/issue23661 ?

[Nick Coghlan]

On 14 July 2015 at 12:28, Robert Collins <robertc at robertcollins.net> wrote:
> On 14 July 2015 at 14:25, R. David Murray <rdmurray at bitdance.com> wrote:
>> On Tue, 14 Jul 2015 14:01:25 +1200, Robert Collins <robertc at robertcollins.net> wrote:
>>> So unittest.mock regressed during 3.5, and I found out when I released
>>> the mock backport.
>>>
>>> The regression is pretty shallow - I've applied the fix to 3.6, its a
>>> one-liner and comes with a patch.
>>>
>>> Whats the process for getting this into 3.5? Its likely to affect a
>>> lot of folk using mock (pretty much every OpenStack project got git
>>> with it when I released mock 1.1).
>>
>> 3.5 hasn't been released yet.  The patch ideally would have gone into
>> 3.5 first, then been merged to 3.6.  As it is, you'll apply it to
>> 3.5, and then do a null merge to 3.6.  It will get released in the
>> next 3.5 beta.
>
> What I'm unclear on is the approval process for doing ^.

During the beta period, 3.5 is open for normal maintenance (i.e.
anything that would be acceptable in a 3.5.1 release).

The 3.5 changes that need a +1 from Larry as release manager are the
ones where beta feedback reveals an "incomplete feature", where we
need to make a more significant change to resolve it that would
normally be disallowed on a maintenance branch (e.g. sorting out the
data model for PEP 492 after Ben Darnell's attempts to integrate
native coroutines with Tornado highlighted a number of shortcomings in
the original design).

The 3.4 branch also remains open for general maintenance until 3.4.4
goes out, at which put I assume Larry will put that branch into
security fix only mode.

I wonder: should we start putting some of these process details for
the different phases in the release PEPs themselves? Larry sent a good
summary to python-committers for 3.5 a while back, but they'd be
easier to find in the PEPs, and it would also make it clear which
aspects a new RM was keeping, and which they wanted to try doing
differently.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia