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

[Nick Coghlan]

On 4 March 2014 16:50, Larry Hastings <larry at hastings.org> wrote:
>
> On 03/03/2014 10:23 PM, Nick Coghlan wrote:
>
> But at the moment you're making it
> *hard* for people to test the release,
>
>
> How?  How is testing against a tarball fundamentally different from testing
> against an hg-cloned repository?
>
> I'm really not buying this.

Because there are *zero* instructions in the devguide for tarball
based testing. Can it be done? Yes. Is it properly documented such
that it is acceptable to rely on it as an essential part of the
release process? No.

*Never* have we done a feature release where we went dark for most of
the release candidate cycle - for past feature releases, the release
branch was made at the time of the first rc, and everything merged
during that time was subject to two committer review, and everything
merged to the release branch was automatically considered as a
candidate for including in the next rc/final release. After the switch
to Mercurial, the contents of the release branch might not be
*exactly* what ended up being released, but they were close enough for
all the purposes that anyone cared about. That's not the case here -
by instituting the new process where you stopped checking every commit
and instead required the creation of specific tracker issues, the
default branch of the main repo now has a bunch of stuff listed for
3.4.1 that is a mixture of 3.4.0 and 3.4.1 changes, so it's hard to
tell whether or not a particular change is going to make it into 3.4
final.

I was prepared to go along with that (since those that do the work get
to make the rules), but then you said you were going to go straight
from a release candidate that broke two of the most popular Python
projects to a final release with the release clone *still* offline for
reasons I do not understand. That is *not* OK - if we're skipping rc3
even though rc2 broke both Flask and SQL Alchemy (and possibly Vim),
then we need to be able to see *exactly* what is going to be
published, including the full history of which commits have been
cherry-picked, not just the end result as a tarball.

You've given people plenty of warning that you'll be rewriting history
in your release clone. That's fine, we can deal, especially for
throwaway testing clones - git users handle rewritten history as a
matter of course, and it really isn't that scary, even in Mercurial.
But the combination of skipping rc3 *and* keeping the release clone
offline is not a responsible course of action.

Regards,
Nick.

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