[Guido]
> It's official: I've changed the patch submission guidelines
> (http://www.python.org/patches/) to point to the patch manager at
> SourceForge. We are no longer bound by CNRI's legal department, so
> the requirement for disclaimers or wet signatures is gone.
Yay! Wonder how long that will last <wink>.
Attached is a first cut at documenting the intended use of SourceForge's
patch status tags, and the workflow associated with patch status changes.
The areas in need of fleshing out are marked with "[xxx ...]". Gripe at
will.
I don't think anyone expects this to work smoothly at first. Strive for
patience, and let's work to make SF a really *good* place for patches!
never-thought-i'd-actually-miss-lotus-notes-ly y'rs - tim
PS: I'll move this (& related info) to a reasonable place eventually, so
don't bother griping about email for now.
Intended use of SourceForge patch status tags
---------------------------------------------
revision 1 26-Jun-2000
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]
Discussion of patches is carried out via
[xxx Python-Dev? patches list? without a mail gateway,
the SourceForge patch interface looks too clumsy
to use for controversial patches]
Accepted
The powers that be have accepted the patch, but it has not
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).
If possible, the submitter should apply the patch and change
the status to Closed.
Else anyone with sufficient power should feel encouraged to
do these on the submitter's behalf.
Rejected
The patch has been reviewed and rejected.
When the objections are addressed, the status may change to
Open again.
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.
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.
Deleted
Bit bucket.
Use only if it's OK for the patch and its SourceForge history
to disappear.
As of 26-June-2000, SF does not actually throw away Deleted
patches, but that may change.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4