Development Rules

From Event-B
Revision as of 12:53, 30 March 2009 by imported>Jastram (New page: === Team === * Everybody who wants to join the project may do so. * Communication Channels are (: ** Email List ** IRC ** Biweekly phone conferences ** Biweekly IRC conferences ** Commit ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Team

  • Everybody who wants to join the project may do so.
  • Communication Channels are (:
    • Email List
    • IRC
    • Biweekly phone conferences
    • Biweekly IRC conferences
    • Commit emails are automatically sent to the developer mailing list to keep all participants up-to-date.
  • We encourage collaboration through Sprints

Conflict Resolution

  • 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

  • Bugs are filed on Sourceforge
  • Bugs are reviewed and assigned a priority by the responsible developers
  • Bugs with priority >=7 are considered critical.
  • In General, no new development by a developer unless all critical bugs assigned to that developer are fixed
  • The five most pressing bugs will be discussed in the regular IRC meetings

Roadmap

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

We document code, architecture and usage.

Release Process

  • 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

  • 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.

Code Ownership

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