[python-committers] Updated schedule for Python 3.4

[Nick Coghlan]

On 16 Jan 2014 21:54, "Kristján Valur Jónsson" <kristjan at ccpgames.com>
wrote:
>
> I suppose different projects have different ways, but I'm actually
talking about commercial projects with which I am somewhat familiar.
> Once a project goes into feature freeze, it is branched off so that
continued feature development can commence, while
> Defects are ironed out in the branch.  Bugs obviously get priority.  This
also applies to open source, I should think.
> Meanwhile, a keen contributor does not have to sit idle waiting for an
extended RC phase to play out.

It's a social hack to remind people that the current focus is supposed to
be on ironing out issues in the imminent release, with the subsequent
release deliberately deemphasised until the current one is out. (PEP 461 is
a bit of an aberration, since people wanted to ensure we had a solid plan
in place for bringing binary interpolation back for 3.5, and also at least
asked the question about doing so in 3.4)

The commercial world has different ways of dealing with the focus problem,
since there's a more direct relationship between an employer and an
employee than there is between a CPython release manager and other
contributors. For us, though, it's useful to have the state of the branches
reflect current priorities (plus we want to minimise the amount of time we
have two maintenance branches open).

Cheers,
Nick.

>
> K
>
> -----Original Message-----
> From: python-committers [mailto:python-committers-bounces+kristjan=
ccpgames.com at python.org] On Behalf Of Matthias Klose
> Sent: Thursday, January 16, 2014 19:27
> To: python-committers at python.org
> Subject: Re: [python-committers] Updated schedule for Python 3.4
>
> Am 16.01.2014 12:17, schrieb Kristján Valur Jónsson:
> > This is such an obvious question that it probably has been raised
before, but anyway:
> > Why not branch 3.4 earlier than release?  That is how big projects are
managed nowadays, you create a staging branch early.
> > I'd suggest branching it off at b3.  There is no reason to keep all
trunk development frozen just because a particular version is in RC mode.
>
> Big projects (like GCC) delay the branching as long as possible and only
branch when the trunk reaches release quality.  Branch maintenance eats
developer resources, and usually opening the trunk for new development
distracts developers from contributing to the release.  I do like the way
how this is done for Python (and GCC).
>
>   Matthias
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140116/a9c90e53/attachment-0001.html>