Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: null

...

  • A JIRA entry is filed, describing the necessary change. See entering bugs and entering issues (word document) for more information on JIRA.
  • The developer who is working on the problem assigns the entry to herself, and develops a change:
    • A change proposal is developed, see some advice PatchAdvice.
    • The developer attaches the change proposal, in "svn diff" format, to the JIRA entry
    • 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 developer signals that the patch is ready to be committed by choosing the "Edit" operation and 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. Remember to check for HandlingAddedOrDeletedFilesInSVNDiff.
  • 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.
    • Wiki Markup
      possibly running some or all of the \[http://svn.apache.org/repos/asf/db/derby/code/trunk/java/testing/README.htm regression test suites\], as the committer deems relevant.
  • When the committer is satisfied satisfies herself 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 (the Jira bug number in the format DERBY-XXX anywhere in the commit message) and to the developer who made the changeand commits it, following the DerbyCommitHowTo.
  • The committer updates the JIRA entry to:
    • clear the "patch available" checkboxmark the issue as resolved, if the issue is complete
    • indicate the version(s) in which it is resolved
    • include a comment with information about the revision number, for example as a hyperlink to the SVN revision viewer for that revision. If the Jira issue number was correctly entered in the svn commit log message, then Jira will automatically pick up the commit message and link to SVN revision viewer in the Subversion Commits tab.
  • Either The committer informs the developer or the original assignee should then verify that the patch was successfully applied, and that the patch has been submitted. The developer should then do some or all of the following, as appropriate for the particular issue and patch:
    • mark the issue as resolved, if the issue is complete
    • indicate the version(s) in which it is resolved
    • add a release note if necessary, following the ReleaseNoteProcess
    • verify that the original problem is now resolved, and
    closes
    • close the JIRA.

Wiki MarkupNote that Derby as a Apache DB sub-project follows the \[http://db.apache.org/guidelines.html Apache DB guidelines\] . This includes the \[http://www.apache.org/foundation/glossary.html#CommitThenReview Commit-Then-Review\] policy. Committers should read the \[http://www.apache.org/dev/new-committers-guide.html overall guidelines for committers\].