Am 17.01.2014 00:57, schrieb Nick Coghlan: > > On 17 Jan 2014 03:25, "Serhiy Storchaka" <storch...@gmail.com > <mailto:storch...@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 _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
