Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Anything in the master branch is deployable (i.e., should always run and generate correct output). Developing directly on the master branch is forbidden.  (But, as a special exception, documentation authoring and fixing may occur directly on master.)
  2. Feature (and bugfix) development must always happen in branches. It is advisable to commit early and often to your branch. You should never merge master into your feature branch; if you need to include changes on master in a feature branch, you should use rebase to rewrite the history of the feature branch such that all feature branch commits happen after all master commits (on the feature branch, just do "git rebase master"). This prevents complex commit histories.
  3. When your feature is ready, push your changes and use the Jenkins continuous integration system to request that it be built and tested, along with the rest of the stack. Be sure to log in (using github credentials) before trying to start a run. Then enter your ticket branch name in the Branch entry and leave the rest as defaulted (i.e. you want to build the entire stack using your ticket and run the demo as a minimal integration test). You can monitor your job on HipChat's "Bot: Jenkins" room. When the Jenkins build passes, ask for your ticket to be reviewed. (Some minor features may not need a review.)
  4. To get your ticket reviewed, from the ticket page in JIRA under Workflow click "In Review". In the resulting dialog box assign a reviewer that you think would be appropriate (they have the option to say they cannot review the change, in which case you will have to choose someone else), add a short comment about what it is you want reviewed, whether an estimate of how long you expect this to be a the review to take ("quick" or a "not quick" reviewis sufficient), and add a link to your completed Jenkins build at the end of the comment. You and the reviewer should get an email requesting the review.
    1. It's up to the reviewer to decide whether to create a github pull request or to just let you merge into master as described below. If they do create a pull request, the review comments will be listed there. If they do not, the review comments will go into the JIRA ticket.
  5. A feature that passes code review is permitted to be merged into master. Merge it (be sure to use the "--no-ff" option, as described below).  Jenkins and buildbot will notice and will build and test it (again).

...