User Tools

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

Site Tools


mantisbt:development_process

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
mantisbt:development_process [2014/01/14 23:07] – created vboctormantisbt:development_process [2014/05/13 15:15] (current) – Added 'Changing external libraries' rombert
Line 1: Line 1:
 ====== Development Process ====== ====== Development Process ======
  
-  * Work should be related to an existing MantisBT issue, if no one exists, create one. +===== Terminology =====
-  * For non-trivial bug fixes or any features, 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. +
-  * Implement the feature / fix in a branch on your [[http://www.github.com/mantisbt/mantisbt|fork of MantisBT on github.com]] and submit a pull request. +
-  * Feedback about the work should be provided within 3-7 days. +
-  * A pull request should include a complete change.  A checkin should never block releasing waiting on follow up work. +
-  * When applicable pull requests should be sent for stable branches. +
-  * Master should always be open to accept contributions.+
  
 +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 [[http://www.github.com/mantisbt/mantisbt/fork|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 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/support
 +
 +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.1389758827.txt.gz · Last modified: 2014/01/14 23:20 (external edit)

Driven by DokuWiki