[Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

[Barry Warsaw]

On Mar 05, 2014, at 09:24 AM, Nick Coghlan wrote:

>I think it's also the fact that new feature releases are rare and changes
>of release manager even more so, meaning there's a fair bit of relearning
>involved every time (since what was appropriate a couple of years earlier
>may not be appropriate the next time, and we'll usually have new developers
>involved that weren't around for the previous release).

This is true.  Be aware though that Larry is in communication with Benjamin,
Georg, and myself, and the PSU is running a closed mailing list for past,
present, and future <wink> release managers[1].

But you're right that the process and tools can change fairly significantly
between releases, and certainly between release manager stints.  We have PEP
101 and a bunch of scripts to automate as much as possible.  I'm fully
supportive of RMs taking on at least two releases in a row, for a similar
reason it makes sense to hold PyconNA's in the same city more than one year in
a row.  Larry has to figure out what works for him on the fly, and I'm
positive that he takes everyone's comments and feedback seriously.  RMing is
just not that easy.  Hopefully, once the heat of the release subsides, we and
Larry can review the process and make whatever changes are necessary for next
time.

>While I'd still strongly prefer an rc3, I think we at least need to get the
>remaining release blockers sorted in the tracker (either fixing them or
>reclassifying them, or else closing them if they're a rejected cherry pick
>request) and a tarball or release clone available for core developer and
>third party testing.

I too would like an rc3, especially to see if issue 19021 can be fixed, which
I suspect will hit a lot of people.  Despite Serhiy's comment (msg212475) I
haven't quite gotten the Ubuntu package working entirely, and I hope to return
to it once I have some other unrelated high priority issues resolved.

It's fine to close as rejected any cherry picks that won't make it into
3.4.0.  For the related bugs that are fixed in trunk though, those marked as
release blockers should IMO be demoted to deferred blockers so they can be
handled in 3.4.1.  (Unless of course the disposition is to not fix them until
3.5).

>I'm being fussy about this for two reasons. Firstly, because my view is the
>same as Victor's: the time between the last rc and the final release should
>be completely uninteresting, with no significant regressions reported
>relative to the previous major version (or any such cases clearly being
>rare enough to wait for the first maintenance release).

I completely agree.  I don't even trust seemingly innocent changes -- they
have broken us before!  Ideally, the only difference between the last rc and
the final release is the version bump.  That may or may not be possible.

>Secondly, I care because I think we need to take into account the social
>benefits of ensuring that we treat third party testers as valued members of
>the release process by giving them a clear chance to confirm that the
>problems they reported have been addressed before we proceed with the
>release. That third party testing does help improve the stability of the
>final release, and wherever practical, we should be doing our best to
>encourage it.

Given how difficult it is to get people to test pre-final release versions, I
definitely agree we need to encourage and support enthusiastic third parties.
We all want to avoid the brown paper bag release. ;)

Cheers,
-Barry

[1] Both the PSU and this mailing list emphatically do not exist.