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

On 16 Jan 2014 21:54, "Kristján Valur Jónsson" kristjan@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=

Sent: Thursday, January 16, 2014 19:27 To: python-committers@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

ccpgames.com@python.org] On Behalf Of Matthias Klose 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@python.org https://mail.python.org/mailman/listinfo/python-committers

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers

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

Oh, only once or twice for every 3.x release so far :)

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.

There's also no reason to not use a personal clone if you want to develop a new feature.

Georg

Am 16.01.2014 14:47, schrieb Antoine Pitrou:

On jeu., 2014-01-16 at 14:22 +0100, Georg Brandl wrote:

...

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

Oh, only once or twice for every 3.x release so far :)

...

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.

There's also no reason to not use a personal clone if you want to develop a new feature.

The question is less for us than for occasional contributors who see their patches or feature requests languish on the tracker, and lose interest.

To be honest, most patches and feature requests languish much longer than the beta period, because of lack of manpower and/or interest of a core developer.

And when a core developer gets interested during the beta period, all they need to do is post "Nice patch/idea, let's discuss and commit it after feature freeze". If the contributor is put off by that, well.

Georg

четвер, 16-січ-2014 15:03:28 Georg Brandl написано:

Am 16.01.2014 14:47, schrieb Antoine Pitrou:

...

The question is less for us than for occasional contributors who see their patches or feature requests languish on the tracker, and lose interest.

To be honest, most patches and feature requests languish much longer than the beta period, because of lack of manpower and/or interest of a core developer.

And when a core developer gets interested during the beta period, all they need to do is post "Nice patch/idea, let's discuss and commit it after feature freeze". If the contributor is put off by that, well.

There are several ready or almost ready patches which did not have time to jump on the train. E.g. C implementation of lru_cache or Kristján's nice enchancement for HTTPResponse (this is only my fault, I just forgot about this patch).

And some my patches wait for review longer than year.

On 17 Jan 2014 03:25, "Serhiy Storchaka" storchaka@gmail.com wrote:

четвер, 16-січ-2014 15:03:28 Georg Brandl написано:

...

Am 16.01.2014 14:47, schrieb Antoine Pitrou:

...

The question is less for us than for occasional contributors who see their patches or feature requests languish on the tracker, and lose interest.

To be honest, most patches and feature requests languish much longer

...

the beta period, because of lack of manpower and/or interest of a core developer.

And when a core developer gets interested during the beta period, all

...

need to do is post "Nice patch/idea, let's discuss and commit it after feature freeze". If the contributor is put off by that, well.

There are several ready or almost ready patches which did not have time to jump on the train. E.g. C implementation of lru_cache or Kristján's nice enchancement for HTTPResponse (this is only my fault, I just forgot about

than they this

patch).

And some my patches wait for review longer than year.

I think a lot of this delay can be removed by adjusting the tooling to make more effective use of core developer time. That's why I have a few tooling discussions on the language summit agenda, primarily the idea of using RhodeCode to power hg.python.org and figuring out how to integrate Zuul with Reitveld, RoundUp, BuildBot and Mercurial to attain an OpenStack style merge gating system where every merge step after a positive review in Reitveld is fully automated.

Cheers, Nick.

---

python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers

On 01/16/2014 06:03 PM, � wrote:

And while I completely understand that core developers enjoy working in 3 much more, it was decided to not accept any improvements for a +2.7 version [...]

You mean, like, new features? Have any new features been put in 2.7 after it hit feature freeze?

-- ~Ethan~

Am 17.01.2014 00:57, schrieb Nick Coghlan:

On 17 Jan 2014 03:25, "Serhiy Storchaka" mailto:storchaka@gmail.com> wrote:

...

четвер, 16-січ-2014 15:03:28 Georg Brandl написано:

...

Am 16.01.2014 14:47, schrieb Antoine Pitrou:

...

The question is less for us than for occasional contributors who see their patches or feature requests languish on the tracker, and lose interest.

To be honest, most patches and feature requests languish much longer than the beta period, because of lack of manpower and/or interest of a core developer.

And when a core developer gets interested during the beta period, all they need to do is post "Nice patch/idea, let's discuss and commit it after feature freeze". If the contributor is put off by that, well.

There are several ready or almost ready patches which did not have time to jump on the train. E.g. C implementation of lru_cache or Kristján's nice enchancement for HTTPResponse (this is only my fault, I just forgot about this patch).

And some my patches wait for review longer than year.

I think a lot of this delay can be removed by adjusting the tooling to make more effective use of core developer time. That's why I have a few tooling discussions on the language summit agenda, primarily the idea of using RhodeCode to power hg.python.org http://hg.python.org and figuring out how to integrate Zuul with Reitveld, RoundUp, BuildBot and Mercurial to attain an OpenStack style merge gating system where every merge step after a positive review in Reitveld is fully automated.

If Zuul is in any way similar to Gerrit, I think that would be very, very useful indeed for attacking this delay.

Georg

On 17 Jan 2014 12:03, "Kristján Valur Jónsson" kristjan@ccpgames.com wrote:

I never got the impression that this was a matter of funding, Nick.

And while I completely understand that core developers enjoy working in 3

much more, it was decided to not accept any improvements for a +2.7 version even from those that would do so voluntarily. This could have be done without making any commitment to release a 2.8 at any point.

Doing that on the core infrastructure requires core developer *time* in order to review the patches. We made it crystal clear we weren't interested in providing that for free, and nobody ever even asked about the possibility of *paid* development to create a Python 2.8.

This is why I drew the comparison. There are barriers put in place to try to achieve a social engineering result.

The only barrier was the core development team deciding not to proceed with 2.x feature development for free any more after the parallel 2.6 and 2.7 releases. The question of paid development has never been discussed. It's only come up now because we're almost two releases into Python 3 only development and commercial Python 2 users are realising there is stuff there that they want that is technically backwards compatible with Python 2.

That means that anyone that wants a Python 2.8 release either needs to fund the development infrastructure for a fork that doesn't involve the existing core development team, or else come to a deal with enough core developers that Guido can be persuaded to approve a "bought & paid for" 2.8 release.

However, given the fact that most interesting backwards compatible changes can already be backported via PyPI, it's highly unlikely that anyone will put up that kind of money. Stackless 2.8 is the sole exception because you *already* have the infrastructure and community in place to maintain a CPython 2 fork, so backporting a few additional changes from CPython 3 really doesn't make a big difference to that workload.

Cheers, Nick.

K

From: Nick Coghlan [mailto:ncoghlan@gmail.com] Sent: Friday, January 17, 2014 7:51 To: Kristján Valur Jónsson Cc: Matthias Klose; python-committers; Martin v. Löwis

Subject: Re: [python-committers] Updated schedule for Python 3.4

On 17 Jan 2014 01:02, "Kristján Valur Jónsson" kristjan@ccpgames.com

...

The hope is that by not adding features to 2.x, people will flock

around 3.x en masse :)

Very few of us think that way - it's that we think Python 3 is a better language in most ways, and it is certainly much easier and more pleasant to work on, which matters a great deal for something many of us are doing as a side project outside work hours. I personally get very annoyed by snide remarks like this suggesting that four years of parallel feature development and eight years of parallel maintenance on a volunteer driven

wrote: project *aren't enough*.

Would you have preferred a Gnome or KDE style transition where the

parallel development periods were measured in months rather than years?

Open source projects are innately engineering driven, and thus vastly

less tolerant of long term technical debt than commercial enterprises that can offer additional financial incentives to tolerate working with old code for backwards compatibility reasons. That's *why* a company like Red Hat can continue to support Python 2.7 out to 2023+, even though upstream community support will end in 2015 - people don't maintain and support old platforms like RHEL3 for fun, we do it because we get *paid*.

CCP could have stepped in at any time and proposed funding (or organising

funding for) a full Python 2.8 release after it became clear that python-dev wasn't going to do it voluntarily, but they, like every other commercial entity, realised doing so was likely not to be cost effective given the preferences of upstream and the extended life cycle of 2.7. It sounds like they may be changing their mind as 2015 nears and the idea of Stackless 2.8 is considered, but that's exactly the way open source *should* work.