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

[codesite-noreply at google.com]

Author: marecki
Date: Mon Apr  6 17:04:06 2009
New Revision: 170

Modified:
    wiki/IssueProcessing.wiki

Log:
Edited wiki page through web user interface.

Modified: wiki/IssueProcessing.wiki
==============================================================================
--- wiki/IssueProcessing.wiki	(original)
+++ wiki/IssueProcessing.wiki	Mon Apr  6 17:04:06 2009
@@ -28,8 +28,30 @@

  == Owners and Reviewers ==

-The *owner* of an issue is a _developer_ assigned to fixing it. He or she  
is indicated by the "Owner" field of the issue.
+The *owner* of an issue is a _developer_ assigned to fixing it. He or she  
is indicated by the "Owner" field of the issue. By default an issue has got  
no owner.

  The *reviewer* of an issue is a person expected to validate fixes provided  
for that issue by the owner. By default this will be the person who  
reported the issue; however, keep in mind the reviewer and the owner of an  
issue must *NOT* be the same person. The reviewer is indicated using labels  
("reviewby-_name_") as well as by being the first on the "Cc" list.

-== TBC ==
\ No newline at end of file
+
+== Filing ==
+
+TBA
+
+
+== Submission of Fixes ==
+
+All fixes should be submitted, in the form of patch files, as attachments  
to issue comments. The recommended format of such patches is 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. 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.
+
+The review is to be provided as a comment or comments on the issue.
+
+If the reviewer submits any code him-/herself, this code must be reviewed  
too before the issue can be considered resolved. The issue should then be  
assigned to a new, independent reviewer should in order to avoid a conflict  
of interests between the owner and the first developer. 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.
+
+Once the (final) reviewer is happy with the fix, he should advance the  
issue to the next stage. If that is not possible for some reason, it should  
be done by one of the project managers.
+
+
+== Closing ==
+
+TBA
+