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