anchor.diff:  diff --git a/src/main/asciidoc/_chapters/developer.adoc b/src/main/asciidoc/_chapters/developer.adoc
   ----
   
  -* If the first line of the patch looks similar to the following (without the `a` and `b`), the patch was created with +git diff --no-prefix+ and you need to add `-p0` to the +git apply+                                        command below.
  +* If the first line of the patch looks similar to the following (without the `a` and `b`), the
  +patch was created with +git diff --no-prefix+ and you need to add `-p0` to the +git apply+ command
  +below.
   +
   ----
   diff --git src/main/asciidoc/_chapters/developer.adoc src/main/asciidoc/_chapters/developer.adoc
   ----
   
   +
  -.Example of Committing a Patch
  +.Example of committing a Patch
   ====
   One thing you will notice with these examples is that there are a lot of +git pull+ commands.
   The only command that actually writes anything to the remote repository is +git push+, and you need to make absolutely sure you have the correct versions of everything and don't have any conflicts before pushing.
  
positive.code: [[submitting.patches]]
  === Submitting Patches
  
  HBase moved to GIT from SVN.
  Until we develop our own documentation for how to contribute patches in our new GIT context, caveat the fact that we have a different branching model and that we don't currently do the merge practice described in the following, the link:http://accumulo.apache.org/git.html[accumulo doc
                      on how to contribute and develop] after our move to GIT is worth a read.
  See also <<git.best.practices,git.best.practices>>.
  
  If you are new to submitting patches to open source or new to submitting patches to Apache, start by reading the link:http://commons.apache.org/patches.html[On Contributing
                      Patches] page from link:http://commons.apache.org/[Apache
                      Commons Project].
  It provides a nice overview that applies equally to the Apache HBase Project.
  
  [[submitting.patches.create]]
  ==== Create Patch
  
  Use _dev-support/submit-patch.py_ to create patches and optionally, upload to jira and update
  reviews on Review Board. Patch name is formatted as (JIRA).(branch name).(patch number).patch to
  follow Yetus' naming rules. Use `-h` flag to know detailed usage information. Most useful options
  are:
  
  . `-b BRANCH, --branch BRANCH` : Specify base branch for generating the diff. If not specified, tracking branch is used. If there is no tracking branch, error will be thrown.
  . `-jid JIRA_ID, --jira-id JIRA_ID` : Jira id of the issue. If set, we deduce next patch version from attachments in the jira and also upload the new patch. Script will ask for jira username/password for authentication. If not set, patch is named <branch>.patch.
  
  The script builds a new patch, and uses REST API to upload it to the jira (if --jira-id is
  specified) and update the review on ReviewBoard (if --skip-review-board not specified).
  Remote links in the jira are used to figure out if a review request already exists. If no review
  request is present, then creates a new one and populates all required fields using jira summary,
  patch description, etc. Also adds this review's link to the jira.
  
  Authentication::
  Since attaching patches on JIRA and creating/changing review request on ReviewBoard requires a
  logged in user, the script will prompt you for username and password. To avoid the hassle every
  time, set up `~/.apache-creds` with login details and encrypt it by following the steps in footer
  of script's help message.
  
  Python dependencies::
  To install required python dependencies, execute
  `pip install -r dev-support/python-requirements.txt` from the master branch.
  
  .Patching Workflow
  
  * Always patch against the master branch first, even if you want to patch in another branch.
    HBase committers always apply patches first to the master branch, and backport if necessary.
  * Submit one single patch for a fix.
    If necessary, squash local commits to merge local commits into a single one first.
    See this link:http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash[Stack Overflow question] for more information about squashing commits.
  * Patch name should be as follows to adhere to Yetus' naming convention.
  +
  ----
  (JIRA).(branch name).(patch number).patch
  ----
  For eg. HBASE-11625.master.001.patch, HBASE-XXXXX.branch-1.2.0005.patch, etc.
  
  * To submit a patch, first create it using one of the methods in <<patching.methods,patching.methods>>.
    Next, attach the patch to the JIRA (one patch for the whole fix), using the  dialog.
    Next, click the btn:[Patch
    Available] button, which triggers the Hudson job which checks the patch for validity.
  +
  Please understand that not every patch may get committed, and that feedback will likely be provided on the patch.
  
  * If your patch is longer than a single screen, also attach a Review Board to the case.
    See <<reviewboard,reviewboard>>.
  * If you need to revise your patch, leave the previous patch file(s) attached to the JIRA, and upload the new one, following the naming conventions in <<submitting.patches.create,submitting.patches.create>>.
    Cancel the Patch Available flag and then re-trigger it, by toggling the btn:[Patch Available] button in JIRA.
    JIRA sorts attached files by the time they were attached, and has no problem with multiple attachments with the same name.
    However, at times it is easier to increment patch number in the patch name.
  
  [[patching.methods]]
  .Methods to Create Patches
  Eclipse::
    Select the  menu item.
  
  Git::
    `git format-patch` is preferred:
       - It preserves the committer and commit message.
       - It handles binary files by default, whereas `git diff` ignores them unless
       you use the `--binary` option.
    Use `git rebase -i` first, to combine (squash) smaller commits into a single larger one.
  
  Subversion::
    Make sure you review <<eclipse.code.formatting,eclipse.code.formatting>> and <<common.patch.feedback,common.patch.feedback>> for code style.
    If your patch was generated incorrectly or your code does not adhere to the code formatting guidelines, you may be asked to redo some work.
  
  [[submitting.patches.tests]]
  ==== Unit Tests
  
  Yes, please.
  Please try to include unit tests with every code patch (and especially new classes and large changes). Make sure unit tests pass locally before submitting the patch.
  
  Also, see <<mockito,mockito>>.
  
  If you are creating a new unit test class, notice how other unit test classes have classification/sizing annotations at the top and a static method on the end.
  Be sure to include these in any new unit test files you generate.
  See <<hbase.tests,hbase.tests>> for more on how the annotations work.
  
  ==== Integration Tests
  
  
negative.code: [[developing]]
  == Developer Guidelines
  
  === Branches
  
  We use Git for source code management and latest development happens on `master` branch. There are
  branches for past major/minor/maintenance releases and important features and bug fixes are often
   back-ported to them.
  
  === Release Managers
  
  