Aahz <aahz@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

Michael Bartl <zeddicus@satokar.com> writes:

What has precedence? Nothing I guess. It's rather a bug in the doc or in the code. Should I contact the original author(s) of tempfile.py, which seem to be Guido and Tim Peters?

Not necessarily. If your common sense dictates that one is better than the other, just explain it so. If you change the code, consider that existing code may break. Don't worry about the potential breakage, instead, document it - both in Misc/NEWS, and, if breakage is likely, in Doc/whatsnew/whatsnew24.tex. Document the change itself in the documentation, using \versionchanged. [You might notice that I have abstained from actually thinking about the change itself :-] Regards, Martin