[Python-Dev] Encouraging developers

[Thomas Wouters]

On 3/5/07, A.M. Kuchling <amk at amk.ca> wrote:
>
> >From <http://ivory.idyll.org/blog/mar-07/five-things-I-hate-about-python
> >:
>
>         4. The patch mafia. I like everyone on python-dev that I meet,
>         but somehow it is annoyingly difficult to get a patch into
>         Python. Like threading, and the stdlib, this is a mixed
>         blessing: you certainly don't want every Joe Schmoe checking
>         in whatever crud he wants. However, the barrier is high enough
>         that I no longer have much interest in spending the time to
>         shepherd a patch through. Yes, this is probably all my fault
>         -- but I still hate it!
>
> 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.
>
> Any ideas for fixing this problem?


A better patch-tracker, better procedures for reviewing patches surounding
this new tracker, one or more proper dvcs's for people to work off of. I'm
not sure about 'identifying core developers' as we're all volunteers, with
dayjobs for the most part, and only a few people seem to care enough about
python as a whole. Putting the burden of patch review on the developers that
say they can cover it might easily burn them out. (I see Martin handle a lot
of patches, for instance, and I would love to help him, but I just can't
find the time to review the patches on subjects I know much about, let alone
the rest of the patches.)

While submitting patches is good, there's a lot more to it than just
submitting the 5-line code change to submit a bug/feature, and reviewing
takes a lot of time and effort. I don't think it's unreasonable to ask for
help from the submitters like we do, or ask them to write tests and docs and
such.

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?


I need to get time, or people need to volunteer to do the work :) It's not
entirely easy to do, depending on the dvcs in question. Canonical will be
getting us an up to date conversion to Bazaar in a couple of weeks or so; I
will be using that, or a Mercurial conversion I do myself, to refactor all
Py3K work into separate branches for easier[*] backporting. I would love to
do one for Monotone too (my personal favourite, but I'm
weird/paranoid/fascinated by the potential and the elegance) -- but I doubt
I'll get the time, and the monotone conversion takes many times as long as
the rest.

Of course, anything I set up for py3k will be accessible by anyone, and it
would include a straight conversion from the trunk, too. And for those
developers that worry about having to switch (or others having to switch)
from svn to something confusing: we'll keep the p3yk branch intact (possibly
after a rebuild) for people to keep submitting patches against. (I could
even grab commits from the svn branch and stuff them into a bzr/hg branch,
but we'll see about that when we get there.)

[*]: by easier, I mean simple, straightforward, explainable, reproducible
and scalable, rather than a godawful pigfucking lot of work that will
undoubedly get messy bugs crept in. I doubt I did all the py3k merges
properly as-is, and that's not dealing with backports yet :)
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070305/db0d0cf4/attachment.htm