Differences

This shows you the differences between two versions of the page.

--- mantisbt:development_process [2014/01/15 02:26] – backport bug fixes only dregad
+++ mantisbt:development_process [2014/05/13 15:15] (current) – Added 'Changing external libraries' rombert
@@ Line 39: / Line 39: @@
   * All work items are expected to be done in 'master' development branch.
   * Work items should be ported to the appropriate release / stable branches. On principle, only bug fixes should be backported, to avoid introduction of regressions in the stable branches.
-  * Targeted branches should be identified during planning stage of a work item and is considered part [dregad - of what ?].
+  * Targeted branches should be identified during planning stage of a work item and is considered part of the discussion.
 ===== Implementing a Work Item =====
-  * Implement work item in a branch on your [[http://www.github.com/mantisbt/mantisbt|fork of MantisBT on github.com]].
+  * Implement work item in a branch on your [[http://www.github.com/mantisbt/mantisbt/fork|own Github fork of MantisBT]].
   * Remember to include any corresponding changes to the manual.
-  * When ready, submit a pull request
+  * When ready, submit a pull request including a description of the changes
 ===== Reviewing a Work Item =====
-  * Developers should code review the change within 3-7 days. (TODO: what sign-off is enough, is it dependent on the change, is there a timeout process?)
+  * Developers should code review the change within 7 days.  Developers can work on other features in parallel, so this shouldn't block them.
+  * There should be at least 2 sign-offs at checkin time. Even with the sign-offs, the waiting time has to be served.
+  * A developer can request vote or DL discussion if there is no agreement on the pull request.
   * Continuous integration system (Travis) must green light the pull request in github.
+  * If a fix is needed for a release or there are urgency, the author can email the developers DL with the reasoning.
 ===== Integrating a Work Item =====
@@ Line 59: / Line 62: @@
   * Make sure the change shows up as developed by original author and signed-off by the core developer.
+===== Release and Branch Management =====
+  * Support latest stable branch.
+  * Support branch that is in stabilization mode (e.g. release candidates).
+  * Developers will actively develop on master, but won't support customer instances on it.  Customers are encouraged to use stable or release candidates for production, but not nightly builds.
+  * Goal is to fork for a major release every 6 months.
+  * Goal is to release a minor release every 2 months including targeted fixes.
+  * Security fixes can trigger immediate releases for stable branches.
+===== Changing external libraries =====
+Adding or removing an external library should be discussed first on the developer mailing list.
+The following must be considered when reviewing an external library
+  * Technical fit
+  * License compatibility
+  * Recent development activity
+  * Community size/support
+Changing versions of a library does not need to be discussed, unless there are major changes in the review criteria, e.g. change of license