[Python-Dev] Encouraging developers

Phil Thompson phil at riverbankcomputing.co.uk
Tue Mar 6 09:48:04 CET 2007

On Tuesday 06 March 2007 6:00 am, Martin v. Löwis wrote:
> Phil Thompson schrieb:
> >>> 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.
> >
> > I don't think that that is true. I think a lot of people care, but many
> > can't do anything about because the barrier to entry is too great.
> He was talking about the committers specifically who don't care about
> Python as-a-whole, and I think this is true. But I also believe that
> many contributors don't "care" about Python as-a-whole, in the sense
> that they are uninterested in learning about implementation details of
> libraries they will never use. What they do care about is the problems
> they have, and they do contribute patches for them.
> >> 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.
> >
> > So there is something wrong there as well.
> >
> >> 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.
> >
> > Of course it's not unreasonable. I would expect to be told that a patch
> > must have tests and docs before it will be finally accepted. However,
> > before I add those things to the patch I would like some timely feedback
> > from those with more experience that my patch is going in the right
> > direction.
> This cannot work. It is very difficult to review a patch to fix a
> presumed bug if there is no test case. You might not be able to
> reproduce the patch without a test case at all - how could you then
> know whether the patch actually fixes the bug?

Please read what I said again. Yes, a patch must be reviewed before 
submission. Yes, a patch when submitted must include docs and test cases. I'm 
talking about the less formal process leading up to that point. The less 
formal process has a much lower barrier to entry, requires much less effort 
by the "reviewer", is the period during which the majority of the teaching 
happens, and will result in a better quality final patch that will require 
less effort to be put in to the final, formal review.

> So I really think patches should be formally complete before being
> submitted. This is an area were anybody can review: you don't need
> to be an expert to see that no test cases are contributed to a
> certain patch.
> If you really want to learn and help, review a few patches, to see
> what kinds of problems you detect, and then post your findings to
> python-dev. People then will comment on whether they agree with your
> review, and what additional changes they like to see.

Do you think this actually happens in practice? There is no point sticking to 
a process, however sensible, if it doesn't get used.


More information about the Python-Dev mailing list