User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:development_process

This is an old revision of the document!


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.
  • Targeted branches should be identified during planning stage of a work item and is considered part .

Implementing 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?)
  • Continuous integration system (Travis) must green light the pull request in github.

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.
mantisbt/development_process.1389768549.txt.gz · Last modified: 2014/01/15 02:21 (external edit)

Driven by DokuWiki