User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:development_process

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mantisbt:development_process [2014/01/15 01:49] – Correct syntax, added links dregadmantisbt:development_process [2014/05/13 15:15] (current) – Added 'Changing external libraries' rombert
Line 33: Line 33:
   * A work item should include a complete change.  A checkin should never require follow up work to get to the shippable bar.   * A work item should include a complete change.  A checkin should never require follow up work to get to the shippable bar.
   * Communicate early what you are working on to avoid duplication, major rework, etc.   * Communicate early what you are working on to avoid duplication, major rework, etc.
 +
  
 ===== Targeting a Work Item to Releases ===== ===== Targeting a Work Item to Releases =====
  
   * All work items are expected to be done in 'master' development branch.   * All work items are expected to be done in 'master' development branch.
-  * Work items should be ported to the appropriate release / stable branches. +  * 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 .+  * Targeted branches should be identified during planning stage of a work item and is considered part of the discussion. 
  
 ===== Implementing a Work Item ===== ===== 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.   * Remember to include any corresponding changes to the manual.
 +  * When ready, submit a pull request including a description of the changes
  
 ===== Reviewing a Work Item ===== ===== 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-offsthe 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.   * 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 ===== ===== Integrating a Work Item =====
Line 56: Line 62:
   * Make sure the change shows up as developed by original author and signed-off by the core developer.   * 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
mantisbt/development_process.1389768549.txt.gz · Last modified: 2014/01/15 02:21 (external edit)

Driven by DokuWiki