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/14 23:38] – Added principles section. vboctor | mantisbt:development_process [2014/05/13 15:15] (current) – Added 'Changing external libraries' rombert | ||
---|---|---|---|
Line 4: | Line 4: | ||
This process will use the 'work item' as a generic terminology for features or bugs. | This process will use the 'work item' as a generic terminology for features or bugs. | ||
+ | |||
===== Principles ===== | ===== Principles ===== | ||
- | * Shipping is what unlocks the value of the checkins we make. Release often. | ||
* Treat each other with respect and value diversity of contributors. | * Treat each other with respect and value diversity of contributors. | ||
- | * Do not get tunnel visioned into your own priorities. | + | * Shipping is what unlocks the value of the checkins we make. Release often. |
+ | * Focus on building the best bug tracker, make use of services like http:// | ||
+ | * Integrate MantisBT with products users use, rather than providing our own clones. | ||
* Focus on productivity of the team, rather than just the individual contributor' | * Focus on productivity of the team, rather than just the individual contributor' | ||
+ | * Do your best to provide design and code review within a reasonable time frame. | ||
+ | * Don't lick too many cookies! | ||
+ | * Do not get tunnel visioned into your own priorities. | ||
+ | * Encourage the community to contribute to the project. | ||
+ | * For non-trivial changes, use public branches and get early feedback. | ||
+ | * Use feature branches, rather than " | ||
+ | * Avoid big bang huge contributions. | ||
+ | * Think twice before making changes that make merge between branches expensive. | ||
* Checkin rights can be earned and lost based on following our principles and process. | * Checkin rights can be earned and lost based on following our principles and process. | ||
- | * Good contributions from the community are always welcome. | ||
===== Planning a Work Item ===== | ===== Planning a Work Item ===== | ||
- | * Work should be related to an existing MantisBT issue, if no one exists, create one. | + | |
- | * For non-trivial bug fixes or any features, describe | + | * Link to or open an issue if you want the work to reflect in the release change log. |
- | * If you need immediate feedback from the core developers, email the dev mailing list with a pointer to your issue. | + | * For non-trivial work items: |
- | * A change | + | |
- | * Contributors / devs should communicate | + | * Describe |
- | * Avoid big bang huge contributions when possible. | + | * If you need immediate feedback from the core developers, email the dev mailing list with a pointer to your issue. |
+ | * A work item should include a complete change. | ||
+ | * Communicate | ||
===== 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 | + | * Implement |
* 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 | + | * Developers should code review the change within 7 days. Developers can work on other features in parallel, so this shouldn' |
- | * Continuous integration system (Travis) must green light the change | + | * 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 | ||
+ | * 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 ===== | ||
+ | |||
+ | * Whenever history is not important, use cherry-pick to integrate the pull request rather than " | ||
+ | * 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. | ||
+ | |||
+ | |||
+ | ===== 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.1389760706.txt.gz · Last modified: 2014/01/14 23:49 (external edit)