[python-committers] Updated schedule for Python 3.4

Georg Brandl g.brandl at gmx.net
Fri Jan 17 06:42:25 CET 2014


Am 17.01.2014 00:57, schrieb Nick Coghlan:
> 
> On 17 Jan 2014 03:25, "Serhiy Storchaka" <storchaka at gmail.com
> <mailto:storchaka at 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



More information about the python-committers mailing list