Difference between revisions of "EclipseLink/Development/Process"

Revision as of 14:51, 30 October 2007

EclipseLink Development Process

This page describes the process committers should use for developing and submitting code to EclipseLink.

Code Submission

All code that is checked into the EclipseLink SVN should have gone through the following steps

• There is a documented reason for the change
  • For bugs, this means an entry in bugzilla
  • For features this means a Functional Specification that describes the goal for the feature and how it is used and a Design Specification that provides an up to date view of how the feature is designed
• Code has been reviewed
  • Code changes should be sent to the eclipselink-dev mailing list in the form of an SVN patch
  • It is the committer's responsibility to ensure that at least one other committer has reviewed the code and agrees it should be committed
  • If there are committers that disagree that the code should be committed, the committers with opposing views should work to come to an agreement and if they do not, ask the EclipseLink Architecture council for guidance
• Code must be tested
  • New regression tests must be added to completely test the feature or bug
  • An accepted set of regression tests for the whole project must pass
• When the code review has been completed the code can be committed into SVN. A descriptive comment that references the bugzilla link or the feature name should be included with the check-in
• When the code is checked in:
  • For bugs, the bugzilla entry must have the final SVN patch attached to it and a short description of the fix should be added to bugzilla
  • For features, you must ensure both the functional specification and the design specification reflect the state of the current code
  • For both, send and email to eclipselink-dev and (when applicable)update bugzilla with the following information
    • The name of the feature or the number of the bug
    • A short description of the bug
    • A pointer to the new tests for the bug, and if they require any special configuration, a description of how to run them
    • A list of the tests that have been run
    • The name of the committer who reviewed the bug

If you want to do a check-in that does not follow this process, send an email to the eclipselink-dev mailing list explicitly saying you are hoping to not follow the process and describing your reasoning. This should only be done in exceptional cases

Development Process TODO list

• Build template for Functional Specification
• Build template for Design Specification
• Define the set of tests that is in our SRG - i.e. The tests that must pass for all submissions