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

[codesite-noreply at google.com]

Author: marecki
Date: Tue Apr 14 14:30:06 2009
New Revision: 173

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:30:06 2009
@@ -45,7 +45,7 @@

  == 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.
+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.

@@ -55,7 +55,7 @@

  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.

-Issues tagged *ReviewedNeedsCommit* should be closed as soon as the  
relevant changes have made their way into the Git repository, by the person  
who performed the commit.
+Issues tagged *ReviewedNeedsCommit* should be closed as soon as the  
relevant changes have made their way into the Git repository, by the person  
who performed the commit. The relevant GitHub branch should be deleted at  
that time as well.


  == Miscellaneous ==