[Python-Dev] Moving bugs and patches through the pipeline more quickly (original) (raw)

Skip Montanaro skip@pobox.com
Wed, 6 Mar 2002 09:58:45 -0600

I'm giving this message a new subject and redirecting it to python-dev, mostly to consider the last two paragraphs. It was originally part of a thread about raw_input() not flushing stdout before emitting its prompt in certain situations.

JG == Jonathan Gardner, MH == Michael Hudson.

JG> I will write another bug report about the unresponsiveness to bug
JG> reports as well, as there are a lot of bugs that aren't even
JG> addressed at sourceforge.

MH> Oh, that will help, sure.

Jonathan> It is a bug. There needs to be a fix for it. Do you need more
Jonathan> volunteers?  How do we get involved? Where do we sign up? What
Jonathan> needs to be done? Maybe there needs to be more coordination
Jonathan> and less coding at the top.

Two things should help move things through the mill faster:

* If you think you know how to fix the bug, submit a patch along with
  your bug report to SF.

* Assign it to just about anybody so someone is notified.  The
  exceptions here are that I don't think you should assign bugs to one
  of the PythonLabs Five (Guido, Tim, Barry, Jeremy, Fred).  Let one of
  the other developers decide if it warrants their attention.

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. It's not immediately obvious to me how this should happen. The first expansion from the original five to roughly the current crop of developers wasn't terribly difficult, because for the most part Guido et al either knew them personally or had a long enough exposure to them on the net to feel confident they would make positive contributions. The overall community is large enough now that not all potentially good developers become visible easily. Requiring a somewhat rigorous vetting process will consume more time for the current developers and distract people from time working on the code base. On the other hand, not requiring any vetting is likely to allow the occasional donkey into the corral with the horses.

There are people here with experience in other large(r) open source projects (Perl, Apache, Mozilla). How do they handle this problem?

-- Skip Montanaro (skip@pobox.com - http://www.mojam.com/)