[Python-Dev] Help offered
Martin v. Löwis
martin at v.loewis.de
Wed Sep 24 03:26:12 EDT 2003
Aahz <aahz at pythoncraft.com> writes:
> Excellent! Currently, it's rather ad-hoc. Just pick a patch that
> interests you and make a comment about its suitability. Make sure to
> check whether the patch comes with appropriate documentation. [*] If
> you don't see activity on the patch within a week or two, feel free to
> ask here. Right now isn't the best time to poke people because we're
> gearing up for the 2.3.1 release.
Also, try to classify the patch somehow, indicating what most likely
the problem is for the patch not being reviewed/accepted:
- the patch might introduce a questionable feature, and nobody has
dared to reject it yet, in order to not offend the submitter. In
that case, voice an opinion (and record it in the patches tracker)
on whether you are in favour of or opposed to the proposed feature
(ideally giving a rationale on why you are). If there are enough
voices showing opposition, the submitter might withdraw the patch.
If there are enough voices in favour, a core developer might
- the patch might be incomplete. Ping the submitter. If the submitter
is incomplete, either complete it yourself, or suggest rejection
of the patch.
- the patch might be so involved that a quick review does not reveal
whether it is correct. I personally find patches involving memory
management bugs to be in that category. Review the patch excessively:
perform tests, study all possible code paths to uncover cases that
have been ignored. When done, record in the patch what kind of review
you have done, and either indicate the problems you have found, or
- the patch might be in an area where the "core" developers have
little expertise; you often find that trivial patches are ignored
just because everybody thought not to be an expert in the subject.
Perform a quick review of the patch to find out whether it meets the
formal criteria (completeness), and whether it is perhaps obviously
correct or obviously incorrect. If not, come up with a strategy
to obtain a decision on the patch:
* become an expert yourself in the subject area, and recommend
acceptance or rejection afterwards. I have done that many times,
and find it both time consuming and rewarding.
* find an expert and have it review the patch
* ask the submitter to clarify all questionable aspects of the
patch, i.e. have him explain the patch to you. If the patch
is for a little-used feature (e.g. for an obscure platform),
it might be acceptable to incorporate incorrect patches, since
nobody will notice, anyway - it might be enough that the submitter
believes the patch is correct.
I personally find processing of patches more important: it takes often
less time per item, brings the project forward, and gives the
contributor the satisfaction of having contributed.
For bug reports, I would recommend the following classification:
- determine whether the report is complete: does the submitter
indicate observed behaviour, expected behaviour? If relevant, OS
version, Python version? Is a test case included (not mandatory,
- determine whether the report is reproducable: try reproducing
it with the included test case, or come up with a test case
yourself (and list it in the bug report). It might be:
* unreproducable: you have the seemingly same setup as the
the submitter, but you fail to reproduce it. Ask the submitter
* fixed: you can reproduce it for the version the submitter has
used (or you are reasonably sure that the bug existed in that
version), yet the problem disappears with the current version.
Indicate that in the report, and recommend to close the
report as fixed.
* hard to reproduce: you cannot reproduce the bug because you
lack some environment. Try to confirm presence of the bug
by reviewing the code, or get yourself access to the missing
- determine whether the report is invalid: is it really a bug?
E.g. is the observed behaviour documented? Is the documentation
silent on this aspect, and the observed behaviour surprising
to experts? If the documented behaviour deviates from the
observed behaviour (and perhaps both from the expected behaviour):
which should be the correct one?
Once you have classified the report, and found it reports a proper
bug, consider asking the submitter for a patch (do so kindly, not
demanding). If it is clear that the submitter is not going to provide
a patch, try developing one yourself.
More information about the Python-Dev