A.M. Kuchling schrieb: > FWIW, I have a related perception that we aren't getting new core > developers. These two problems are probably related: people don't get > patches processed and don't become core developers, and we don't have > enough core developers to process patches in a timely way. And so > we're stuck.
I think this perception is partially wrong. The number of unreviewed patches has been sitting around 400 for quite some time now - so it has not been getting worse. This is mostly thanks to the (very) few reviewers that deal with patches in areas out of their primary interest. I'd like to mention Georg Brandl here. I also doubt that accepting patches more quickly would give many more patch reviewers. Most submitters are happy if their patch is accepted, and couldn't care less about other people's patches. This is fine, of course - it just means that becoming more responsive (by whatever means) would not necessarily sustain. > Any ideas for fixing this problem? I had this long-term offer of a 5:1 deal. I wish more current committers would offer a similar deal, then we would be able to promise this policy prominently. This, of course, requires that committers are willing to deal with patches even if they are no experts in the subject (i.e. they will need to become experts in the process of reviewing). It might be possible to reverse this policy also: we could decide that committers maintain their write privilege only if they process patches (say, one patch per month). That would be quite intrusive, so I doubt that committers will agree to it. > Tangentially related: > At PyCon, there was general agreement that exposing a read-only > Bazaar/Mercurial/git/whatever version of the repository wouldn't be > too much effort, and might make things easier for external people > developing patches. Thomas Wouters apparently has private scripts > that perform the conversion. What needs to be done to move ahead with > this idea? If it is this "distributed repository" aspect that people are after, I suggest they use svk (http://svk.elixus.org/view/HomePage). People can use it now if they want to, no need to provide additional infrastructure. For other systems, there is a choice of either hosting them at svn.python.org as well (i.e. dinsdale), or having the community host them. For dinsdale hosting, it requires a volunteer to set it up and maintain it. Given the low number of volunteers available for such tasks, I doubt this can work. For community hosting, again there is little administration necessary: hosters can already mirror svn.python.org, and run whatever conversion scripts are necessary. In this case, the task would be merely to communicate that people can already do that if they want to. Regards Martin P.S. I'm really pissed as being described as member of a mafia. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
