db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "DerbyCommitProcess" by BryanPendleton
Date Thu, 23 Feb 2006 16:23:53 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by BryanPendleton:
http://wiki.apache.org/db-derby/DerbyCommitProcess

------------------------------------------------------------------------------
  Here's a brief description of the overall Derby change commit process. The details may vary
from change to change.
  
   * A JIRA entry is filed, describing the necessary change
-  * The developer who is working on the problem assigns the entry to herself.
+  * The developer who is working on the problem assigns the entry to herself, and develops
a change:
-  * A change proposal is developed.
+    * A change proposal is developed.
-  * The developer attaches the change proposal, in "svn diff" format, to the JIRA entry
+    * The developer attaches the change proposal, in "svn diff" format, to the JIRA entry
-  * Other Derby developers review the change proposal and provide feedback.
+    * Other Derby developers review the change proposal and provide feedback.
-  * The above three steps are repeated until there is consensus that the change is ready.
+    The above three steps are repeated until there is consensus that the change is ready.
-  * The developer signals that the patch is ready to be committed by checking the "patch
available" checkbox.
+  * The developer signals that the patch is ready to be committed by checking the "patch
available" checkbox. The developer may also send a message to derby-dev requesting the attention
of a committer.
   * A committer sends a message to derby-dev indicating that she intends to review and commit
the change.
   * The committer applies the patch to the current trunk and verifies that it applies cleanly
and passes derbyall.
-  * The committer reviews the change. Good practices to follow here include: close reading
of the diff, exploratory testing of specific changes of interest, verifying that the regression
test(s) fail without the code change(s) and pass once the code changes are applied.
+  * The committer reviews the change. Good practices to follow here include: 
+    * close reading of the diff, 
+    * exploratory testing of specific changes of interest, 
+    * verifying that the regression test(s) fail without the code change(s) and pass once
the code changes are applied.
   * When the committer is satisfied that the change is ready, the committer issues the "svn
commit" to commit the change. In the commit log message, the committer should include information
that ties back to the JIRA issue and to the developer who made the change.
-  * The committer updates the JIRA entry to clear the "patch available" checkbox and to mark
the issue as resolved. It is useful to include a comment with information about the revision
number, for example as a hyperlink to the SVN revision viewer for that revision.
+  * The committer updates the JIRA entry to:
+    * clear the "patch available" checkbox 
+    * mark the issue as resolved
+    * include a comment with information about the revision number, for example as a hyperlink
to the SVN revision viewer for that revision.
   * Either the developer or the original assignee should then verify that the patch was successfully
applied, and that the original problem is now resolved, and closes the JIRA.
  

Mime
View raw message