anchor.diff:  
   
   == Preparing A Release Candidate
  +
  +. Before building a release candidate, make sure you have followed the
  +Apache committer guide for setting up your GPG keys
  +(link:https://www.apache.org/dev/new-committers-guide.html#set-up-security-and-pgp-keys[here]).
   
   . When close to building a release candidate, try building a source tarball
   (on a supported platform):
  
positive.code: 
  . About another 24 hours later, delete the previous minor version in the branch
    you released from, from SVN. For example, if you released 1.2.1, delete `1.2.0`.
  
  . Update the version number on the branch you released from back to a SNAPSHOT
    for the next patch release, such as `1.6.1-SNAPSHOT` after the `1.6.0` release.
  
negative.code:   have to perform this step because SSH access is behind a firewall. The steps
    are as follows:
    1. Ensure your public SSH key is in `~gerrit/.ssh/authorized_keys` on gerrit.cloudera.org
    2. From behind the firewall, `ssh gerrit.cloudera.org` to log in.
    3. Change to the gerrit user, `sudo su gerrit`
    4. Back up the existing replication configuration file by executing
       `cp ~/etc/replication.config ~/etc/replication.config.bak.`date '+%Y%m%d.%H%M%S'``
    5. Edit `etc/replication.config` to add a line for the new branch, such as `branch-1.x.y`
    6. Send email to the dev lists for Kudu and Impala (dev@kudu.apache.org and
       dev@impala.apache.org) indicating that you are going to restart Gerrit
       (link:https://s.apache.org/2Wj7[example]). It is best to do the restart at
       some time of day when you don't expect many people to be using the system,
       since Gerrit can take a few minutes to restart.
    7: Restart Gerrit, `~/bin/gerrit.sh restart`
  
  . As needed, patches can be cherry-picked to the new branch.
  
  