[Python-Dev] Revision 2 of Patch Manager guidelines

[Tim Peters]

I believe the attached addresses all questions (but no "new feature
requests") that were raised.  Note especially the new threat to do "random
assignment" of incoming patches, the new request that you comment on patches
assigned to you at least weekly, and the new request that you take yourself
off of patches you're assigned to but not actively pursuing.  We already
have patches just sitting there without action or comment for no apparent
reason, and *something* has to force those to move along.

at-least-now-we-can-see-which-patches-those-are-ly y'rs  - tim



Intended use of SourceForge patch status & "assigned to" fields
---------------------------------------------------------------
revision 2                                          09-Jul-2000

In general, the status field should be close to self-explanatory, and the
"assigned to" field should be the person responsible for taking the next
step in the patch process.  Both fields are expected to change value over
the life of a patch; the normal workflow is detailed below.

When you've got the time and the ability, feel free to move any patch that
catches your eye along, whether or not it's been assigned to you.  And if
you're assigned to a patch but aren't going to take reasonably quick action
(for whatever reason), please assign it to someone else ASAP:  at those
times you can't actively help, actively get out of the way.

If you're an expert in some area and know that a patch in that area is both
needed and non-controversial, just commit your changes directly -- no need
then to get the patch mechanism involved in it.

You should add a comment to every patch assigned to you at least once a
week, if only to say that you realize it's still on your plate.  This rule
is meant to force your attention periodically:  patches get harder & harder
to deal with the longer they sit.

Open
    The initial status of all patches.
    The patch is under consideration, but has not been reviewed yet.
    The status will normally change to Accepted or Rejected next.
    The person submitting the patch should (if they can) assign it to the
        person they most want to review it.
    Else the patch will be assigned via
        [xxx a list of expertise areas should be developed]
        [xxx but since this hasn't happened and volunteers are too few,
             random assignment is better than nothing:  if you're a Python
             developer, expect to get assigned out of the blue!]
    Discussion of major patches is carried out on the Python-Dev mailing
        list.  For simple patches, the SourceForge comment mechanism should
        be sufficient.
        [xxx an email gateway would be great, ditto Ping's Roundup]

Accepted
    The powers that be accepted the patch, but it hasn't been applied yet.
        [xxx flesh out -- Guido Bottleneck avoidable here?]
    The status will normally change to Closed next.
    The person changing the status to Accepted should, at the same time,
        assign the patch to whoever they believe is most likely to be able &
        willing to apply it (the submitter if possible).

Closed
    The patch has been accepted and applied.
    The previous status was Accepted, or possibly Open if the submitter was
        Guido (or moral equivalent in some particular area of expertise).

Rejected
    The patch has been reviewed and rejected.
    When the objections are addressed, the status may change to Open again.
    The person changing the status to Rejected should assign the patch back
        to the submitter, or if it's clear the patch will never be accepted,
        assign it to None.
    Note that SourceForge allows the submitter to overwrite the patch with a
        new version.

Out of date
    Previous status was Open or Accepted or Postponed, but the patch no
        longer works.
    Please enter a comment when changing the status to "Out of date", to
        record the nature of the problem and the previous status.  Also
        assign it back to the submitter, as they need to upload a new
        version (note that SourceForge will not allow anyone other than the
        original submitter to update the patch).

Postponed
    The previous status was Open or Accepted, but for some reason (e.g.,
        pending release) the patch should not be reviewed or applied until
        further notice.
    The status will normally change to Open or Accepted next.
    Please enter a comment when changing the status to Postponed, to record
        the reason, the previous status, and the conditions under which the
        patch should revert to Open or Accepted.  Also assign the patch to
        whoever is most likely able and willing to decide when the status
        should change again.

Deleted
    Bit bucket.
    Use only if it's OK for the patch and its SourceForge history to
        disappear.
    As of 09-July-2000, SF does not actually throw away Deleted patches, but
        that may change.