[Python-Dev] Python 3.4: Cherry-picking into rc2 and final

Nick Coghlan ncoghlan at gmail.com
Wed Feb 19 22:18:50 CET 2014

On 20 Feb 2014 04:18, "Georg Brandl" <g.brandl at gmx.net> wrote:
> Am 19.02.2014 19:00, schrieb Georg Brandl:
> > Am 19.02.2014 16:50, schrieb Guido van Rossum:
> >> On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl <g.brandl at gmx.net
> >> <mailto:g.brandl at gmx.net>> wrote:
> >>
> >>     Am 19.02.2014 00:54, schrieb Barry Warsaw:
> >>     > On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
> >>     >
> >>     >>Am 17.02.2014 00:25, schrieb Larry Hastings:
> >>     >>> And my local branch will remain private until 3.4.0 final
> >>     >>
> >>     >>sorry, but this is so wrong. Is there *any* reason why to keep
this branch
> >>     >>private?
> >>     >
> >>     > IMO, no.  read-only for !larry sure, but not private.
> >>
> >>     I emphatically agree.  There is no need at all for secrecy, or
> >>
> >>     And it is very understandable that vendors (or even "just" our
> >>     building experts) want to make as many tests with what will be RC2
> >>     then final as they can, to catch possible issues before release.
> >>
> >>
> >> That's why it's RC2 and not 3.4final, right? Once Larry says it's
> >> everyone *will* have a chance to test it. What value is a preview of
the preview
> >> really going to add?
> >
> > Ned told me just a few days ago that he does regular pre-tag builds of
the OSX
> > installers, and as for the Debian/Ubuntu side Barry can say more.  The
> > with the RCs is that as long as you add patches during the RC phase
(which is
> > more or less unavoidable if the schedule is to be kept), the state of
> > release branch can only profit from more eyes.
> There's even some helpful people on #python-dev (like Arfrever from
Gentoo) who
> frequently do post-push reviews, catching embarrassing bugs before they
> sneak their way into a release (thank you Arfrever!).
> OK, that's my reasoning, I'm going to fucking shut up now.

I suspect everyone is also highly aware of the fact that there are some
ambitious changes in 3.4, the release of rc1 is bringing the usual wave of
additional third party testing that has picked up some interesting
regressions and usability issues (e.g. the Alembic test suite found a fun
one in the inspect module, while the pip installation doesn't currently
play nice with UAC on Windows), and the Ubuntu 14.04 deadline restricts our
ability to add a 3rd rc.

That brings with it a strong desire to parallelise things as much as
possible, and read only access to the upcoming release helps greatly in
knowing which regressions have already been addressed, allowing third party
testers to more easily focus on any remaining issues.

A "user beware, this may be rebased without warning" clone would be fine
for that purpose, and I suspect in most cases just running rc2 -> final
with such a clone available (preserving Larry's current workflow until rc2)
would be sufficient to address most concerns.


> Georg
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140220/fbe05380/attachment.html>

More information about the Python-Dev mailing list