Development Rules - Revision history

imported>Mathieu: Category:Work in progress

2009-08-12T12:45:46Z

← Older revision		Revision as of 12:45, 12 August 2009
Line 76:		Line 76:
	* 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]]

imported>Jastram at 08:50, 20 April 2009

2009-04-20T08:50:47Z

← Older revision		Revision as of 08:50, 20 April 2009
Line 14:		Line 14:
	* We encourage collaboration through Sprints		* We encourage collaboration through Sprints

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

	* Conflicts or disagreements shall be discussed.		* Conflicts or disagreements shall be discussed.
Line 39:		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 (~~agreed)~~ ===		=== Documentation (not discussed ===

	We document code, architecture and usage.		We document code, architecture and usage.
Line 55:		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 (~~agreed~~) ===		=== 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 71:		Line 71:
	** A failure in any of the product's features will result in the product build to fail.		** A failure in any of the product's features will result in the product build to fail.

	=== Code Ownership (~~agreed~~) ===		=== 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.

imported>Jastram: provide "agreed" status for each section.

2009-04-20T08:36:44Z

provide "agreed" status for each section.

← Older revision		Revision as of 08:36, 20 April 2009
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.
Line 14:		Line 14:
	* We encourage collaboration through Sprints		* We encourage collaboration through Sprints

	=== Conflict Resolution ===		=== Conflict Resolution (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 and Feature Requests (collectively called artefacts) 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]
Line 27:		Line 27:
	* The 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 39:		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 (agreed) ===

	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 55:		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 (agreed) ===

	* 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 71:		Line 71:
	** A failure in any of the product's features will result in the product build to fail.		** A failure in any of the product's features will result in the product build to fail.

	=== Code Ownership ===		=== Code Ownership (agreed) ===

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

imported>Jastram: /* Tests / Continuous Integration */

2009-04-20T08:34:13Z

Tests / Continuous Integration

← Older revision		Revision as of 08:34, 20 April 2009
Line 63:		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 ===

imported>Laurent: /* Bug Tracking */ IRC meeting 2009-04-01

2009-04-02T08:06:21Z

Bug Tracking: IRC meeting 2009-04-01

← Older revision		Revision as of 08:06, 2 April 2009
Line 21:		Line 21:
	=== Bug Tracking ===		=== Bug Tracking ===

	* 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 ===

imported>Laurent: /* Team */ commit mailing list + cleanup

2009-04-02T08:00:00Z

Team: commit mailing list + cleanup

← Older revision		Revision as of 08:00, 2 April 2009
Line 5:		Line 5:
	* 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]
	** ~~Commit emails~~ are automatically sent to ~~the~~ IRC channel [irc://irc.freenode.net/#rodin #rodin] ~~to keep all participants up-to-date.~~		** Commits are also automatically sent to IRC channel [irc://irc.freenode.net/#rodin #rodin]
	** Commit emails are automatically sent to the ~~developer~~ mailing list ~~to keep all participants up-to-date. ''Question: necessary with all the other communication channels?''~~		** Commit emails are automatically sent to the commit mailing list
	* We encourage collaboration through Sprints		* We encourage collaboration through Sprints

imported>Fabian at 14:39, 1 April 2009

2009-04-01T14:39:29Z

← Older revision		Revision as of 14:39, 1 April 2009
Line 10:		Line 10:
	** 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]
			** Commit emails are automatically sent to the IRC channel [irc://irc.freenode.net/#rodin #rodin] to keep all participants up-to-date.
			** Commit emails are automatically sent to the developer mailing list to keep all participants up-to-date. ''Question: necessary with all the other communication channels?''
	* We encourage collaboration through Sprints		* We encourage collaboration through Sprints

imported>Laurent: Draft notice

2009-04-01T13:17:45Z

Draft notice

← Older revision		Revision as of 13:17, 1 April 2009
Line 1:		Line 1:
			{{TODO\|This is a draft currently under discussion, not yet endorsed by the project}}

	=== Team ===		=== Team ===

imported>Laurent: /* Team */ Added mailing lists URL + IRC channels + CIA VC feed

2009-03-31T12:05:03Z

Team: Added mailing lists URL + IRC channels + CIA VC feed

← Older revision		Revision as of 12:05, 31 March 2009
Line 3:		Line 3:
	* 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 ~~List~~		** 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]
	** 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
	** ~~Commit emails~~ are ~~automatically sent to the developer mailing list to keep all participants up~~-to-~~date.~~		** Commits are available through RSS feeds from [http://cia.vc/stats/project/rodin-b-sharp CIA VC]
	* We encourage collaboration through Sprints		* We encourage collaboration through Sprints

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

2009-03-30T12:53:50Z

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

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 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 [https://sourceforge.net/tracker/?group_id=108850 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 [http://wiki.eclipse.org/Version_Numbering#Guidelines_on_versioning_plug-ins Eclipse Version Numbering Scheme].
* The Provisional API Guideline may be used: [http://wiki.eclipse.org/Provisional_API_Guidelines_Update_Proposal]
* 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.