[Python-Dev] Moving bugs and patches through the pipeline more quickly

Mark Hammond mhammond@skippinet.com.au
Thu, 7 Mar 2002 15:38:17 +1100


[Skip]
> As the Python user base grows I think we do need a way to expand the
> developer pool without a lot of effort because the amount of feedback is
> always going to be proportional to the number of users.

Let me first get the most benign comments out of the way first: I hate
sourceforge's bug manager!!  I have fallen in love with bugzilla, as it
works oh-so well.  I know it is too easy to blame the tools, but having a
discrete CC list per-bug really works well.  At the moment I have 129 unread
messages in my python-bugs folder - only because I wiped it out a week or so
ago.

However, I think the real problem lies in the basic fact that developers
tend to scratch their itches.  Python is mature enough that many of the bugs
are obscure and don't really affect anyone in the main Python community.  A
case in point - I have submitted and steered through checkin 3 Mozilla bugs
in the last week - all stupid bugs related to newsgroup threading that I had
to live with every day.  I couldn't take it any more :)  There are no such
Python bugs assigned to me or rotting.

Secondly, as Guido said, more people is not the simple answer.  Often you
simply need to mail around and find a "champion" in the developer list.
Find someone who is kind-hearted (ie, everyone listed as developers :) who
you can convince to go through the motions.  Convince them that it scratches
*your* itch, and you will still pique their interest.  In bugzilla you would
rope in others by adding them to the CC list and pleading for their help :)

In Mozilla, the formal process helps.  To quote Martin:
"""
I think people should be encouraged to comment on bugs and
patches. I'll recognize an educated comment when I see it. E.g. if
there is a patch where the first comment says "change this for that
reason", the second comment says "what about documentation", and the
third is "ok, I've implemented all these requirements", then I'm
willing to apply the patch without any deeper analysis.
"""

This is really all that Mozilla does, and maybe is worth formalizing for us.
Our process could state:

* A person with CVS checkin privileges will be assigned to the bug, and is
ultimately the "approver" of the patch.  They need not be intimately
familiar with the code, but must satisfy themselves that people intimately
familiar with the code think it is OK, and indeed it is "Pythonic".  They
can ask as many people as they like to review the patch, or review the scope
of the patch.

* All patches must be reviewed by someone "credible".  "credible" is fuzzy,
and up to the ultimate approver, but must be someone the approver would
trust given the nature of the patch.  eg, mhammond may be credible for win32
specific patches, but not linux specific patches!

* It is *not* the responsibility of the approver to chase up reviewers.
Whoever wants this patch checked in can chase up reviewers.  Occasionally
this will be the approver, but not often.  The point here is: don't bother
harassing whoever is assigned the bug when the bug does not have any
reviews.

* The approver then performs the actual checkin, running the tests etc and
coping with the fallout.  If the approver can not be stirred into action,
then it is acceptable to mail python-dev pleading for someone to take this
most excellent, heavily reviewed patch on for the good of all mankind.

In the example that spawned this thread:  Jonathon could mail me saying
"could you please have a look at bug xxx.  It has been reviewed by Skip and
isn't really that deep".  I would say "sure", and have a cursory look at the
bug, noting Skip's comments.  Worst case I would ask a few question to try
and make me look clever, fail miserably, and apply the patch locally.  I
would build Linux and Windows, and run the test suite.  Then just check it
in.

This is almost a "mozilla-light" process.  Their process is at
http://www.mozilla.org/hacking/ and it works well for them.  We don't need
it all, but probably could use some.

Mark.