Development Rules: Difference between revisions

From Event-B
Jump to navigationJump to search
← Older edit
imported>Laurent
m Draft notice
imported>Mathieu
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{TODO|This is a draft currently under discussion, not yet endorsed by the project}}
{{TODO|This is a draft currently under discussion, not yet endorsed by the project}}


=== Team ===
=== Team (agreed)===


* Everybody who wants to join the project may do so.
* Everybody who wants to join the project may do so.
* Communication Channels are (:
* Communication Channels are (:
** Email Lists [http://sourceforge.net/mailarchive/forum.php?forum_name=rodin-b-sharp-announce Rodin announce]  [http://sourceforge.net/mailarchive/forum.php?forum_name=rodin-b-sharp-user Rodin user]  [http://sourceforge.net/mailarchive/forum.php?forum_name=rodin-b-sharp-devel Rodin development]
** Email Lists [http://sourceforge.net/mailarchive/forum.php?forum_name=rodin-b-sharp-announce Rodin announce]  [http://sourceforge.net/mailarchive/forum.php?forum_name=rodin-b-sharp-user Rodin user]  [http://sourceforge.net/mailarchive/forum.php?forum_name=rodin-b-sharp-user Rodin user]  [http://sourceforge.net/mailarchive/forum.php?forum_name=rodin-b-sharp-commit Rodin commit]
** Chats [irc://irc.freenode.net/#deploy Deploy IRC]  [irc://irc.freenode.net/#rodin Rodin IRC]
** Chats [irc://irc.freenode.net/#deploy Deploy IRC]  [irc://irc.freenode.net/#rodin Rodin IRC]
** Biweekly phone conferences
** Biweekly phone conferences
** Biweekly IRC conferences
** Biweekly IRC conferences
** Commits are available through RSS feeds from [http://cia.vc/stats/project/rodin-b-sharp CIA VC]
** Commits are available through RSS feeds from [http://cia.vc/stats/project/rodin-b-sharp CIA VC]
** Commits are also automatically sent to IRC channel [irc://irc.freenode.net/#rodin #rodin]
** Commit emails are automatically sent to the commit mailing list
* We encourage collaboration through Sprints
* We encourage collaboration through Sprints


=== Conflict Resolution ===
=== Conflict Resolution (not agreed) ===


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


=== Bug Tracking ===
=== Bug Tracking (agreed) ===


* Bugs are filed on [https://sourceforge.net/tracker/?group_id=108850 Sourceforge]
* Bugs and Feature Requests (collectively called artefacts) are filed on [https://sourceforge.net/tracker/?group_id=108850 Sourceforge]
* Bugs are reviewed and assigned a priority by the responsible developers
* Artefacts are reviewed and assigned a priority by the responsible developers
* Bugs with priority >=7 are considered critical.
* 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 are fixed
* In general, no new development by a developer unless all critical bugs assigned to that developer have been fixed
* The five most pressing bugs will be discussed in the regular IRC meetings
* The most pressing bugs will be discussed in the regular IRC meetings


=== Roadmap ===
=== 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:
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:
Line 37: Line 39:
* Release punctuality takes precedence over feature inclusion. (A feature should be postponed to the next release if it cannot be completed before code freeze).
* 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 ===
=== Documentation (not discussed ===


We document code, architecture and usage.
We document code, architecture and usage.


=== Release Process ===
=== 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.
* Releases will take place four times a year, on March 1st, June 1st, September 1st and December 1st of every year.
Line 53: Line 55:
* During code freeze, Rodin users are invited for testing the Release Candidate
* During code freeze, Rodin users are invited for testing the Release Candidate


=== Tests / Continuous Integration ===
=== Tests / Continuous Integration (not discussed) ===


* It is strongly encouraged to write unit tests for the code's functionality
* It is strongly encouraged to write unit tests for the code's functionality
Line 61: Line 63:
* Failed builds (failed tests count as a failed build) are reported to all developers via email.
* 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.
* 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 ([http://cruise.cs.uni-duesseldorf.de/dashboard/tab/builds 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 ===
=== Code Ownership (not discussed) ===


* There is no code ownership
* There is no code ownership
* There may be a Coordinator for some components.
* There may be a Coordinator for some components.
* Before major refactorings or extensions, all developers must be informed.
* Before major refactorings or extensions, all developers must be informed.
[[Category:Work in progress]]

Latest revision as of 12:45, 12 August 2009

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 (:
  • 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.
Retrieved from ‘https://wiki.event-b.org/index.php?title=Development_Rules&oldid=3679’