[Python-Dev] Help offered

[Martin v. Löwis]

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
  accept it.

- 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
  recommend acceptance.

- 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,
  but desirable)?
- 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
    for clarification.
  * 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
    environment.
- 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.

Regards,
Martin