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/19 17:43] – Added 'Release and Branch Management' section. vboctormantisbt:development_process [2014/05/13 15:15] (current) – Added 'Changing external libraries' rombert
Line 50: Line 50:
 ===== 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 58: Line 61:
   * When the history is important, use the "github merge" button.   * When the history is important, use the "github merge" button.
   * 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 ===== ===== Release and Branch Management =====
Line 64: Line 68:
   * Support branch that is in stabilization mode (e.g. release candidates).   * 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.   * 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 quarter (end of March, June, September, December)+  * Goal is to fork for a major release every 6 months
-  * Goal is to release a minor release every month including security fixes and targeted bug fixes.+  * 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.1390171403.txt.gz · Last modified: 2014/01/19 19:16 (external edit)

CC Attribution-Noncommercial-Share Alike 4.0 International Driven by DokuWiki