[Python-Dev] Cherry-pick between Python 3.4 RC2 and final?
Nick Coghlan
ncoghlan at gmail.com
Tue Mar 4 04:58:48 CET 2014
On 4 March 2014 13:35, Larry Hastings <larry at hastings.org> wrote:
> On 03/03/2014 01:38 PM, Nick Coghlan wrote:
>
> Related question - have you decided yet whether or not to do an rc3?
>
> I ask, as I believe it would be good to give the folks like Mike Bayer and
> Armin Ronacher (who picked up test coverage gaps in rc2 via the Alembic and
> Flask test suites respectively) a chance to rerun their tests before we
> declare 3.4 final.
>
>
> I hadn't planned on it. I'll reach out to those two and see if they can
> deal with tarballs, rather than requiring binary installers--if tarballs
> works for them, I'll steer them towards the 3.4 merge status tarballs and
> ping them when I spin up some new ones.
All of our development guides for testing against trunk are designed
around running from a Mercurial checkout - it would *really* be whole
lot easier for everyone else that is trying to test the release if you
could just do a push from your release clone to a server side clone on
hg.python.org (the link to create one is on
http://hg.python.org/cpython/, and then it's just a hg push to publish
a mirror of the exact state of your current clone).
If you don't want to do an rc3 despite the cherry picked changes since
rc2, then you need to make it easy for people to test the changes
directly from the release branch. An opaque intermittently updated
tarball is not acceptable when none of our infrastructure is designed
to work that way. I was OK with just the tarball when I assumed you
would an rc3 if non-trivial defects were found in rc2. If that's not
the case, then we *need* a public mirror of your release clone.
Regards,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list