On 14 July 2015 at 12:28, Robert Collins <robertc@robertcollins.net> wrote:

On 14 July 2015 at 14:25, R. David Murray <rdmurray@bitdance.com> wrote:

...

On Tue, 14 Jul 2015 14:01:25 +1200, Robert Collins <robertc@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@gmail.com | Brisbane, Australia

On 14 July 2015 at 17:19, Stephen J. Turnbull <stephen@xemacs.org> wrote:

Nick Coghlan writes:

...

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.

It may be overkill, but my take would be a BCP PEP that summarizes consensus best practice as well as option rules for releases, and then each release would have its own PEP briefly describing any deviations from the BCP, including both "I use variant A" and "I'm experimenting with practice Alpha". The former should be explained in the BCP, the rationale for the latter in the release PEP.

That would be the developer's guide, rather than a new PEP: https://docs.python.org/devguide/devcycle.html Unfortunately, I forgot that page existed earlier that, otherwise I would have linked to it in my original reply. Assuming the release managers agree explicitly referencing those definitions from the release PEPs would be a good idea, I figure the actual formatting of the additions would be their call. As an example though, given Larry's approach of calling out his experiments as Sphinx notes, it would likely be sufficient to just say "See the `development lifecycle guide <https://docs.python.org/devguide/devcycle.html#stages>`__ for committer expectations during the different development stages". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia