[pygr-notify] [pygr commit] r174 - Edited wiki page through web user interface.

[codesite-noreply at google.com]

Author: marecki
Date: Tue Apr 14 14:34:38 2009
New Revision: 174

Modified:
    wiki/IssueProcessing.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueProcessing.wiki
==============================================================================
--- wiki/IssueProcessing.wiki	(original)
+++ wiki/IssueProcessing.wiki	Tue Apr 14 14:34:38 2009
@@ -40,6 +40,7 @@

  Open issues without owners, i.e. all *New* and *Accepted* ones, should  
have their respective owner field set to  
_pygr-bug-wranglers at googlegroups.com_, a mailing list of people responsible  
for managing issues, thus letting them know an issue has appeared which  
needs an owner.

+After an issue has been given an owner
  TBC


@@ -47,11 +48,13 @@

  For Pygr developers the preferred form of fix submission is to create a  
dedicated branch *issueXXX* in our main GitHub repository  
(git://github.com/ctb/pygr.git) and commit all code there. In case of  
everyone without write access to that repository, all fixes should be  
submitted, in the form of patch files (preferably in the format generated  
by the _git format-patch_ command, preserving commit history of development  
work; this should be observed particularly rigorously in case of  
large-scale fixes), as attachments to issue comments. Regardless of the  
method, if both functional and non-functional changes are made by the fix,  
they should be provided as separate patches/commits.

-After the fix has been posted, the issue should be advanced - normally by  
the developer who submits the fix, otherwise by one of the project managers  
- to the _FixedNeedsReview_ stage. Not that a reviewer *must* be assigned  
before the issue can be advanced thus.
+After the fix has been posted, the issue should be advanced - normally by  
the developer who submits the fix, otherwise by one of the project managers  
- to the *FixedNeedsReview* stage. Not that a reviewer *must* be assigned  
before the issue can be advanced thus.

-The review is to be provided as a comment or comments on the issue.
+The review is to be provided as a comment or comments on the issue and  
accompanied by an appropriate change of status (see below).

  If the reviewer submits any code him-/herself, this code must be reviewed  
too before the issue can be considered resolved. Normally it should be  
enough for the owner to sign off the changes made by the reviewer, if  
however a conflict arises between the two the issue should then be assigned  
to a new, independent reviewer. Note that such a reassignment is only  
necessary if the reviewer _submits code_; if the reviewer replies with  
comments but actual changes to the code are made by the owner, no such  
change is necessary.
+
+Should the fix be deemed incomplete or incorrect, the issue should be  
demoted back to *Accepted* so that it is clear it must still be worked on.

  Once the (final) reviewer is happy with the fix, he should update the  
issue's status *ReviewedNeedsCommit* or *Closed*, depending on whether the  
relevant code  to the next stage. If that is not possible for some reason,  
it should be done by one of the project managers.