[Python-checkins] CVS: python/nondist/sf-html sf-faq.html,1.18,1.19

2001年3月15日 22:26:17 -0800

Update of /cvsroot/python/python/nondist/sf-html
In directory usw-pr-cvs1:/tmp/cvs-serv12304/python/nondist/sf-html
Modified Files:
	sf-faq.html 
Log Message:
Update Patch Manager guidelines to jibe w/ SourceForge's reassignment of
tags between the Resolution and Status fields.
Index: sf-faq.html
===================================================================
RCS file: /cvsroot/python/python/nondist/sf-html/sf-faq.html,v
retrieving revision 1.18
retrieving revision 1.19
diff -C2 -r1.18 -r1.19
*** sf-faq.html	2001年02月15日 15:31:56	1.18
--- sf-faq.html	2001年03月16日 06:26:14	1.19
***************
*** 62,66 ****
 <h2><a href="#appendix">A. Appendix</a></h2>
 <ol>
! <li><a href="#a1">Patch Manager Guidelines [22.08.2000]</a></li>
 <li><a href="#a2">Python Patch Submission Guidelines [29.06.2000]</a></li>
 </ol>
--- 62,66 ----
 <h2><a href="#appendix">A. Appendix</a></h2>
 <ol>
! <li><a href="#a1">Patch Manager Guidelines [16.03.2001]</a></li>
 <li><a href="#a2">Python Patch Submission Guidelines [29.06.2000]</a></li>
 </ol>
***************
*** 466,475 ****
 <h3><a name="a1" id="a1"></a>A.1.: Patch Manager Guidelines</h3>

! <h4>Intended use of SourceForge patch status &amp; "assigned to" fields</h4>
! Revision 3 <br />
! 22-Aug-2000

! <p>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.</p>
--- 466,475 ----
 <h3><a name="a1" id="a1"></a>A.1.: Patch Manager Guidelines</h3>

! <h4>Intended use of SourceForge patch Resolution, Status &amp; "Assigned To" fields</h4>
! Revision 4 <br />
! 16-Mar-2001

! <p>In general, the Resolution and Status fields 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.</p>
***************
*** 491,501 ****
 </p>

! <h4>Open</h4>

 <blockquote>
! The initial status of all patches.<br />
 The patch is under consideration, but has not been reviewed yet, or
 is under review but not yet Accepted or Rejected.<br />
! The status will normally change to Accepted or Rejected next.<br />
 The person submitting the patch should (if they can) assign it to the person
 they most want to review it.<br />
--- 491,501 ----
 </p>

! <h4>Status Open, Resolution None</h4>

 <blockquote>
! The initial state of all patches.<br />
 The patch is under consideration, but has not been reviewed yet, or
 is under review but not yet Accepted or Rejected.<br />
! The Resolution will normally change to Accepted or Rejected next.<br />
 The person submitting the patch should (if they can) assign it to the person
 they most want to review it.<br />
***************
*** 508,515 ****
 [xxx an email gateway would be great, ditto Ping's Roundup]<br />
 For the reviewer: If you're certain the patch should be applied,
! change the status to Accepted and assign it back to the submitter (if
 possible) for checkin. If you're certain the patch should never be
! accepted, change the status to Rejected and assign it to None. If you
! have specific complaints that would cause you to change your mind,
 explain them clearly in a comment, leave the status Open, and reassign
 back to the submitter. If you're uncertain, leave the status Open, explain
--- 508,515 ----
 [xxx an email gateway would be great, ditto Ping's Roundup]<br />
 For the reviewer: If you're certain the patch should be applied,
! change the Resolution to Accepted and assign it back to the submitter (if
 possible) for checkin. If you're certain the patch should never be
! accepted, change the Resolution to Rejected, Status to Closed, and assign it to None.
! If you have specific complaints that would cause you to change your mind,
 explain them clearly in a comment, leave the status Open, and reassign
 back to the submitter. If you're uncertain, leave the status Open, explain
***************
*** 518,570 ****
 Open and bring it up on Python-Dev.</blockquote>

! <h4>Accepted</h4>

 <blockquote>
 The powers that be accepted the patch, but it hasn't been applied yet. [xxx
 flesh out -- Guido Bottleneck avoidable here?]<br />
! The status will normally change to Closed next.<br />
! 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 &amp; willing to
 apply it (the submitter if possible).</blockquote>

! <h4>Closed</h4>

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

! <h4>Rejected</h4>

 <blockquote>
 The patch has been reviewed and rejected.<br />
 There are generally no transitions out of this state: the patch is dead.<br />
! The person changing the status to Rejected should assign it to None.<br />
 </blockquote>

! <h4>Out of date</h4>

 <blockquote>
! Previous status was Open or Accepted or Postponed, but the patch no longer
 works.<br />
! Please enter a comment when changing the status to "Out of date", to record
! the nature of the problem and the previous status.<br />
! 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).</blockquote>

! <h4>Postponed</h4>

 <blockquote>
! 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.<br />
! The status will normally change to Open or Accepted next.<br />
! 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.</blockquote>

! <h4>Deleted</h4>

 <blockquote>
--- 518,569 ----
 Open and bring it up on Python-Dev.</blockquote>

! <h4>Status Open, Resolution Accepted</h4>

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

! <h4>Status Closed, Resolution Accepted</h4>

 <blockquote>
 The patch has been accepted and applied.<br />
! The previous Resolution was Accepted, or possibly None if the submitter was
 Guido (or moral equivalent in some particular area of expertise).</blockquote>

! <h4>Status Closed, Resolution Rejected</h4>

 <blockquote>
 The patch has been reviewed and rejected.<br />
 There are generally no transitions out of this state: the patch is dead.<br />
! The person setting this state should also assign the patch to None.<br />
 </blockquote>

! <h4>Status Open, Resolution Out of date</h4>

 <blockquote>
! Previous Resolution was Accepted or Postponed, but the patch no longer
 works.<br />
! Please enter a comment when changing the Resolution to "Out of date", to record
! the nature of the problem and the previous state.<br />
! Also assign it back to the submitter, as they need to upload a new version.
! </blockquote>

! <h4>Status Open, Resolution Postponed</h4>

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

! <h4>Status Deleted</h4>

 <blockquote>