[Python-Dev] Becoming a python contributor
Martin v. Loewis
01 Nov 2002 08:56:14 +0100
Gustavo Niemeyer <firstname.lastname@example.org> writes:
> At the same time, I've seen Guido and others bothered a few times
> because of the lack of man power. So the question is: how do I, a
> developer which feels capable of helping in python's development, can
> get some of the tasks which take your time out of your hands? Or even,
> how is it possible to improve some part of the development process by
> giving people like me some instructions?
To me, the most important aspect I'd like to hand off is the review of
patches; to Tim, it is the analysis of bug reports.
There is an ever-growing backlog of both of these (atleast for
patches, we are in the state where just less than 100 are pending, so
it's not that badly growing).
It is clearly unsatisfying for submitters of both patches and bug
reports if they don't hear anything. While some of these issues are
tricky and require expertise not everybody might have, I'd still like
to see more people getting involved with that.
For reviewing of patches, I'd suggest the following guidelines:
- start with the oldest patches, and work forward to the more recent
ones (the most recent ones are regularly checked by several people,
and applied or rejected if a quick decision is possible - but
some of these slip through)
- for each patch, try to find out if it
a) is present (if not, post a notice saying that the upload is missing),
b) applies to the Python source code cleanly (if not, either update the
patch yourself, or request that the submitter does that),
c) does what it says it does (no detailed analysis necessary yet)
(if it is not clear what the patch does, or how it does that,
d) is appropriate for inclusion, by comparison to other features
that are already in Python (if not, ask submitter for a rationale
why this patch should be included, pointing out your objections),
e) has undesirable side effects (if yes, ask the submitter for
an evaluation why these side effects are acceptable),
f) is complete (new features need documentation, bug fixes need
regression test cases if possible),
g) is correct: try compiling it to see whether it works, try to come
up with boundary cases to see whether it still works, inspect
it to see if you find any flaws...
- if you find problems with the patch, post a note asking for
correction. If you find there is already a note and the submitter
hasn't acted for quite some time (10% of the entire life of the
patch on SF), set a deadline at which time it will be rejected.
If there is already a commentary from the submitter, re-perform the
- If you find that you are not qualified to review the patch, still
try to perform as many steps as you can. Don't hesitate to ask the
submitter to explain things to you that you don't understand.
- If you complete evaluation, propose rejection or acceptance. From
time to time, post a list of patches that you think we should act
upon. If I find your analysis convincing, I'll execute the proposed
For bug reports, a similar procedure applies. Check:
- if the bug report is reproducable,
- whether this is a bug at all, or perhaps a misunderstanding on the
part of the submitter, and the documentation clearly says otherwise,
- if there is a patch included, analyse the patch,
- if there is no patch, but you can see how the bug would be fixed,
ask the submitter (politely) whether he would like to write a patch,
- see whether you can write a patch yourself.
If you can't create a patch, dealing with a bug report might be
tricky. If you can see a solution, but can't work on it, post your
analysis into the bug report. If you think the bug is unfixable,
explain this as well. If fixing the bug requires expertise that you
know has, ask the submitter of who might have this expertise
(especially when it comes to strange systems).
> Also, isn't it easy to point out what's wrong in a commit from
> someone who is following the development process for a while than
> taking the time to review its code in the sourceforge patch system?
I'm not sure what you are proposing here? That all patches are just
applied, and then backed-out if incorrect?
While this may be appropriate sometimes, I think it would cause to
many disturbances. It happens from time to time that people reading
python-checkins find problems by inspection. More often, they find
problems some time afterwards, because of unexpected side effects.
This is a good thing, and it is possible only because the patches had
been reviewed carefully on SF.
> My feeling is that the Python development is currently overly
> centralized, and that you might be suffering from that now, by being
> unable to handover some of your tasks to someone else.
I agree with your first observation, but disagree with the second:
there are plenty of tasks that could be handed over. There are just no
volunteers to perform these tasks.
> I feel that everytime I send a patch, besides being contributing,
> I'm also overloading you with more stuff to review and comment and
> etc. Perhaps the fallback costs for some wrong commit is too high
> now (did I heard someone mentioning subversion?)?!
It's not that. Patches *must* be reviewed, or else they would be just
incomplete: people might commit the patch, but fail to commit the
documentation. Then, for a couple of years, there would be no
documentation. Likewise for test cases. That the patch works is alone
not good enough.
It is time-consuming to produce high-quality software. However, that
should not alone be a reason to give up the high standards of Python