[Python-Dev] Encouraging developers

"Martin v. Löwis" martin at v.loewis.de
Tue Mar 6 06:20:37 CET 2007

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.


P.S. I'm really pissed as being described as member of a mafia.

More information about the Python-Dev mailing list