mantisbt:development_process
This is an old revision of the document!
Table of Contents
Development Process
Terminology
This process will use the 'work item' as a generic terminology for features or bugs.
Principles
- Treat each other with respect and value diversity of contributors.
- 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://github.com and http://travisci.com rather than hosting or building your own.
- Integrate MantisBT with products users use, rather than providing our own clones.
- Focus on productivity of the team, rather than just the individual contributor's productivity.
- Do your best to provide design and code review within a reasonable time frame.
- Don't lick too many cookies! Focus on few things and make solid progress. Otherwise, you just are blocking others.
- 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 “person” or “team” branches. Feature branches are easier to review and integrate compared to a branch that has N tangled features.
- Avoid big bang huge contributions.
- Think twice before making changes that make merge between branches expensive. Such changes may not be necessary or may need to be timed to reduce merging overhead on developers.
- Checkin rights can be earned and lost based on following our principles and process.
Planning a Work Item
- For trivial work items:
- Link to or open an issue if you want the work to reflect in the release change log.
- For non-trivial work items:
- Work should be related to an existing MantisBT issue, if no one exists, create one.
- Describe the suggested work in the issue.
- If you need immediate feedback from the core developers, email the dev mailing list with a pointer to your issue. The feedback should be captured directly in the issue rather than the mailing list.
- 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.
Targeting a Work Item to Releases
- All work items are expected to be done in 'master' development branch.
- 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 of the discussion.
Implementing a Work Item
- Implement work item in a branch on your own Github fork of MantisBT.
- 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
- 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-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 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
- Whenever history is not important, use cherry-pick to integrate the pull request rather than “github's merge” to avoid the extra merge commit that happens in such case.
- 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.
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 quarter (end of March, June, September, December).
- Goal is to release a minor release every month including security fixes and targeted bug fixes.
mantisbt/development_process.1390177007.txt.gz · Last modified: 2014/01/19 19:17 (external edit)