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/15 02:21] – added pull request submission dregad | mantisbt: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 work item should include a complete change. | ||
* Communicate early what you are working on to avoid duplication, | * Communicate early what you are working on to avoid duplication, | ||
+ | |||
===== Targeting a Work Item to Releases ===== | ===== Targeting a Work Item to Releases ===== | ||
* All work items are expected to be done in ' | * All work items are expected to be done in ' | ||
- | * 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:// | + | * Implement work item in a branch on your [[http:// |
* Remember to include any corresponding changes to the manual. | * Remember to include any corresponding changes to the manual. | ||
- | * When ready, submit a pull request | + | * When ready, submit a pull request |
===== 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 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/ | ||
+ | |||
+ | 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.1389770498.txt.gz · Last modified: 2014/01/15 02:26 (external edit)