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. 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 satisfies herself that the change is ready, and commits it, following the DerbyCommitHowTo.
  • The committer updates the JIRA entry to:
    • clear the "patch available" checkbox
    • 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.
  • The committer informs the developer 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 close the JIRA.

Note that Derby as a Apache DB sub-project follows the Apache DB guidelines . This includes the Commit-Then-Review policy. Committers should read the overall guidelines for committers.

  • No labels