mantisbt:development_process
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:development_process [2014/01/19 17:43] – Added 'Release and Branch Management' section. vboctor | mantisbt: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 | + | * Developers should code review the change within 7 days. |
+ | * 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 | ||
* 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 " | * When the history is important, use the " | ||
* 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 | + | * Goal is to release a minor release every 2 months |
+ | * 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/ | ||
+ | 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)