RetroSearch Browse

Thu Sep 25 12:24:05 EDT 2003 · http://mail.python.org/pipermail/python-dev/2003-September/038300.html

Hi all!

I've written a draft for a PEP - Guidlines for processing patches.
Please have a look at it and give me some feedback. Private mail is
prefered so not to spam the list ;)

Please note that credits for the current content go to Martin v. Löwis.

regards,
    Michael Bartl
-------------- next part --------------
PEP: ---
Title: Guidelines for Processing Patches
Version: ---
Author: gnosticus at gmx.at (Michael Bartl)
Status: Draft
Type: Informational
Created: 25-Sep-2003
Post-History:

Introduction

    This PEP contains guidelines how to process patches for the
    Python project on SourceForge[1]. Still to be done is to collect
    a list of people willing to process patches and their areas of
    expertise.

Guidelines

    1.  Try to classify the patch somehow, indicating what most likely
        the problem is for the patch not being reviewed/accepted.

    1.1 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.

    1.2 The patch might be incomplete. Try to contact the submitter for a
        complete version. If the submitter is unreachable or does not want
        to finish the work, either complete it yourself, or suggest
        rejection of the patch.

    1.3 The patch might be so complex/involved that a quick review does not
        reveal whether it is correct. 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.

    2.  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:

    2.1 Become an expert yourself in the subject area, and recommend
        acceptance or rejection afterwards. This is a both time consuming
        and rewarding effort.

    2.2 Find an expert and have it review the patch (have a look at the
        people posting to python-dev more than occassionally).

    2.3 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.

References

    [1] http://sourceforge.net/projects/python

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2003-September/038300.html below:

[Python-Dev] PEP draft - Guidelines to processing patches