On 20 Feb 2014 04:18, "Georg Brandl" <g.brandl@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@gmx.net
> >> <mailto:g.brandl@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 ships!
> >>     >>
> >>     >>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 paranoia.
> >>
> >>     And it is very understandable that vendors (or even "just" our binary
> >>     building experts) want to make as many tests with what will be RC2 and
> >>     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 baked,
> >> 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 thing
> > 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 the
> > 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 can
> 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.

Regards,
Nick.

>
> Georg
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com