Development Rules

TODO: This is a draft currently under discussion, not yet endorsed by the project

Team (agreed)

• Everybody who wants to join the project may do so.
• Communication Channels are (:
  • Email Lists Rodin announce Rodin user Rodin user Rodin commit
  • Chats Deploy IRC Rodin IRC
  • Biweekly phone conferences
  • Biweekly IRC conferences
  • Commits are available through RSS feeds from CIA VC
  • Commits are also automatically sent to IRC channel #rodin
  • Commit emails are automatically sent to the commit mailing list
• We encourage collaboration through Sprints

Conflict Resolution (not agreed)

• Conflicts or disagreements shall be discussed.
• If no consent can be found, a decision shall be found by vote in the regular IRC meeting.

Bug Tracking (agreed)

• Bugs and Feature Requests (collectively called artefacts) are filed on Sourceforge
• Artefacts are reviewed and assigned a priority by the responsible developers
• Artefacts with a priority of 9 are considered critical.
• In general, no new development by a developer unless all critical bugs assigned to that developer have been fixed
• The most pressing bugs will be discussed in the regular IRC meetings

Roadmap (not agreed)

A roadmap is maintained for the upcoming releases (at least 12 month ahead) of the platform and plugins. This can be based on Current Development. It contains:

• Features that will be included (with priorities)

• A fixed date when code freeze takes place (see below).

• A fixed date for the release (see below).

• Release punctuality takes precedence over feature inclusion. (A feature should be postponed to the next release if it cannot be completed before code freeze).

Documentation (not discussed

We document code, architecture and usage.

Release Process (not agreed)

• Releases will take place four times a year, on March 1st, June 1st, September 1st and December 1st of every year.
• Feature and Plug-In Version numbers evolve independently.
• TODO: Discuss Product Version Number
• Starting with Rodin 1.0.0, all Eclipse Plug-Ins must follow the Eclipse Version Numbering Scheme.
• The Provisional API Guideline may be used: [1]
• No release if even a single test is broken.
• Have a Code Freeze two weeks before release. The time to the release date is used for testing. Only bugfixes for the upcoming release are allowed during code freeze.
• New development during code freeze must take place on a branch.
• During code freeze, Rodin users are invited for testing the Release Candidate

Tests / Continuous Integration (not discussed)

• It is strongly encouraged to write unit tests for the code's functionality
• All tests must succeed on code that is checked into the trunk.
• Continuous integration is used to test if the software is buildable.
• Tests are run in continuous integration several times a day respectively after each check-in.
• Failed builds (failed tests count as a failed build) are reported to all developers via email.
• Before fixing a bug, a test case must be created that tests the objective condition.
• CruiseControl Build Structure
  • Currently, a CruiseControl (CC) conntinuous integration System is hosted and maintained by Düsseldorf (CruiseControl at Düsseldorf)
  • For each feature, there is a CC project.
  • Each feature project is marked as failed if the compilation fails or if the unit tests fail
  • Features may have dependencies on other features. Test failures in dependent features are not propagated.
  • For each product there is a CC project.
  • A failure in any of the product's features will result in the product build to fail.

Code Ownership (not discussed)

• There is no code ownership
• There may be a Coordinator for some components.
• Before major refactorings or extensions, all developers must be informed.