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

Thu, 15 Mar 2001 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>