Changes (2)

This page describes the basic procedures around submitting code for Couchbase Server.

h3. Why do we need this?

As we are growing, understanding the changes that went into a specific DP, or release gets increasingly hard. The QE, PM, documentation and SDK teams all need to make sure we understand exactly what exactly has been changed.

Commit messages alone are a poor tool for this. Major changes often have very many commits and for people outside of the component, it is often impossible to tell whether a specific commit is part of a specific feature or bug fix. Therefore we need to have a simpler way to reduce the information and understand what was addressed in a build.

* Multiple commits can use the same JIRA reference. There is no need to change any practice regarding breaking up fixes or features into many commits. * This does not apply only for bugs, but also for features or other engineering debt type tasks. As all server development teams (and a few others) have already switched to JIRA for task planning as well, features or refactoring tasks etc should all should have a CBD task. * If there are ongoing background tasks (e.g. code cleanup, or refactoring as some new feature gets implemented) it is recommended to open a CBD task and keep it open, if required across sprints and attribute commits to those tasks, to clarify purpose, without having to create lots and lots of tickets. * There is a special provision for trivial changes, see below.

At some point, changes will be rejected if they do not conform to the rules above.

h4. Trivial Change Provision The purpose of the procedure is to help increase visibility and create clarity, not to create tons of micro JIRA tasks. Therefore the following changes are accepted as trivial changes: * Typo correction * Updated Log messages * Addition, removal or extension of comments * Code reformatting

*Trivial changes still need a JIRA reference*. However, we have defined that [MB-100|http://www.couchbase.com/issues/browse/MB-100] is designated as the reference for trivial issues. So please use it as the reference for trivial changes as defined above. The reason why we need a special reference for these trivial changes is so that we can differentiate between accidentally omitted JIRA references and trivial changes.