You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@accumulo.apache.org by bu...@apache.org on 2014/12/14 18:57:25 UTC
svn commit: r932721 - in /websites/staging/accumulo/trunk/content: ./
versioning.html
Author: buildbot
Date: Sun Dec 14 17:57:25 2014
New Revision: 932721
Log:
Staging update by buildbot for accumulo
Added:
websites/staging/accumulo/trunk/content/versioning.html
Modified:
websites/staging/accumulo/trunk/content/ (props changed)
Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun Dec 14 17:57:25 2014
@@ -1 +1 @@
-1641305
+1645479
Added: websites/staging/accumulo/trunk/content/versioning.html
==============================================================================
--- websites/staging/accumulo/trunk/content/versioning.html (added)
+++ websites/staging/accumulo/trunk/content/versioning.html Sun Dec 14 17:57:25 2014
@@ -0,0 +1,645 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE- 2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1">
+ <link href="/css/bootstrap.min.css" rel="stylesheet">
+ <link href="/css/bootstrap-theme.min.css" rel="stylesheet">
+ <link href="/css/dataTables.bootstrap.css" rel="stylesheet">
+ <!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
+ <!--[if lt IE 9]>
+ <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
+ <script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
+ <![endif]-->
+ <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>
+ <script src="/js/bootstrap.min.js"></script>
+ <script src="/js/jquery.dataTables.min.js"></script>
+ <script src="/js/dataTables.bootstrap.js"></script>
+ <link href="/css/accumulo.css" rel="stylesheet" type="text/css">
+ <link href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css" rel="stylesheet">
+ <title>Apache Accumulo Git WIP</title>
+
+<script>
+ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+ m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+ })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+ ga('create', 'UA-50934829-1', 'apache.org');
+ ga('send', 'pageview');
+
+</script>
+
+</head>
+
+<body>
+<nav class="navbar navbar-default navbar-fixed-top" role="navigation">
+<div class="container-fluid">
+ <div class="navbar-header">
+ <button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#navbar-items">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+ <a class="navbar-brand" href="/index.html">Accumulo</a>
+ </div>
+ <div class="collapse navbar-collapse" id="navbar-items">
+ <ul class="nav navbar-nav">
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown" href="#">
+ Project <span class="caret"></span>
+ </a>
+<ul class="dropdown-menu">
+<li id="nav_index"><a href="/index.html">Home</a></li>
+<li id="nav_downloads"><a href="/downloads">Downloads</a></li>
+<li id="nav_features"><a href="/notable_features.html">Features</a></li>
+<li><a href="http://www.apache.org/licenses/LICENSE-2.0"><i class="fa fa-external-link"></i> License</a></li>
+</ul>
+</li>
+
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown" href="#">
+ Community <span class="caret"></span>
+ </a>
+<ul class="dropdown-menu">
+<li id="nav_getinvolved"><a href="/get_involved.html">Get Involved</a></li>
+<li id="nav_mailinglists"><a href="/mailing_list.html">Mailing Lists</a></li>
+<li id="nav_people"><a href="/people.html">People</a></li>
+<li id="nav_blog"><a href="https://blogs.apache.org/accumulo/">Blog</a></li>
+<li class="divider"></li>
+<li class="dropdown-header">Governance</li>
+<li id="nav_bylaws"><a href="/bylaws.html">Bylaws</a></li>
+<li id="nav_consensusbuilding"><a href="/governance/consensusBuilding.html">Consensus Building</a></li>
+<li id="nav_lazyconsensus"><a href="/governance/lazyConsensus.html">Lazy Consensus</a></li>
+<li id="nav_releasing"><a href="/governance/releasing.html">Releasing</a></li>
+<li id="nav_voting"><a href="/governance/voting.html">Voting</a></li>
+</ul>
+</li>
+
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown" href="#">
+ Development <span class="caret"></span>
+ </a>
+<ul class="dropdown-menu">
+<li id="nav_source"><a href="/source.html">Source & Guide</a></li>
+<li id="nav_git"><a href="/git.html">Git Workflow</a></li>
+<li id="nav_contrib"><a href="/contrib.html">Contrib Projects</a></li>
+<li id="nav_rb"><a href="/rb.html">Review Board</a></li>
+<li id="nav_releasing"><a href="/releasing.html">Making Releases</a></li>
+<li><a href="https://issues.apache.org/jira/browse/accumulo"><i class="fa fa-external-link"></i> Issues</a></li>
+<li><a href="https://builds.apache.org/view/A-D/view/Accumulo/"><i class="fa fa-external-link"></i> Builds</a></li>
+</ul>
+</li>
+
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown" href="#">
+ Documentation <span class="caret"></span>
+ </a>
+<ul class="dropdown-menu">
+<li class="dropdown-header">Manual</li>
+<li><a href="/1.5/accumulo_user_manual.html">1.5</a></li>
+<li><a href="/1.6/accumulo_user_manual.html">1.6</a></li>
+<li class="divider"></li>
+<li class="dropdown-header">Javadoc</li>
+<li><a href="/1.5/apidocs">1.5</a></li>
+<li><a href="/1.6/apidocs">1.6</a></li>
+<li class="divider"></li>
+<li class="dropdown-header">Examples</li>
+<li id="nav_examples_1_5"><a href="/1.5/examples">1.5</a></li>
+<li id="nav_examples_1_6"><a href="/1.6/examples">1.6</a></li>
+<li class="divider"></li>
+<li id="old_documentation"><a href="/old_documentation.html">Docs for Older Verisons</a></li>
+<li id="nav_screenshots"><a href="/screenshots.html">Screenshots</a></li>
+<li id="nav_papers"><a href="/papers.html">Papers & Other Links</a></li>
+<li id="nav_glossary"><a href="/glossary.html">Glossary</a></li>
+</ul>
+</li>
+
+ <li class="dropdown">
+ <a class="dropdown-toggle" data-toggle="dropdown" href="#">
+ ASF Links <span class="caret"></span>
+ </a>
+<ul class="dropdown-menu">
+<li><a href="http://www.apache.org"><i class="fa fa-external-link"></i> Apache Software Foundation</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html"><i class="fa fa-external-link"></i> Sponsorship</a></li>
+<li><a href="http://www.apache.org/security/"><i class="fa fa-external-link"></i> Security</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html"><i class="fa fa-external-link"></i> Thanks</a></li>
+</ul>
+</li>
+</ul>
+
+<form method="GET" action="http://search-hadoop.com/" class="navbar-form navbar-right" role="search">
+ <div class="form-group">
+ <input type="text" name="q" class="form-control" placeholder="Search"/>
+ <input type="hidden" name="fc_project" value="Accumulo"/>
+ </div>
+ <button type="submit" class="btn btn-default"><span class="glyphicon glyphicon-search"></span></button>
+</form>
+ </div>
+
+</div>
+</nav>
+
+
+<div class="container-fluid">
+<div class="row">
+ <div class="col-md-2" id="sidebar">
+ <div style="text-align: center">
+ <a href="/index.html"><img id="logo" alt="Apache Accumulo ™" class="img-responsive" src="/images/accumulo-logo.png"/></a>
+ <br>
+Latest 1.6 release: <strong>1.6.1</strong><br>
+Latest 1.5 release: <strong>1.5.2</strong><br>
+ <br>
+ <a id="download-button-sidebar" class="btn btn-success btn-block" href="/downloads/" role="button">Download</a>
+ </div>
+ <hr>
+<table class="table" id="sociallinks">
+<tr><td><img src="/images/Twitter_logo_blue.png" style="height: 1em"></td><td><a href="https://twitter.com/apacheaccumulo">@ApacheAccumulo</a></td></tr>
+<tr><td><img src="/images/InBug-16px_0.png"></td><td><a href="https://www.linkedin.com/groups/Apache-Accumulo-Professionals-4554913">Apache Accumulo Professionals</a></td></tr>
+<tr><td><img src="/images/GitHub-Mark-32px.png" style="height: 1em"></td><td><a href="https://github.com/apache/accumulo">apache / accumulo</a></td></tr>
+<tr><td><span class="glyphicon glyphicon-comment"></span></td><td><a href="irc://chat.freenode.net/accumulo">#accumulo @ freenode</a></td></tr>
+<tr><td><img src="/favicon.png" width="16" /></td><td><a href="http://blogs.apache.org/accumulo">Apache Accumulo Blog</a></td></tr>
+</table>
+<hr>
+<a id="accumulo-summit-logo" href="http://accumulosummit.com/"><img alt="Accumulo Summit" class="img-responsive" src="/images/accumulo-summit-2014.png"></a>
+ </div>
+ <div class="col-md-8 col-md-offset-1">
+<!--
+ <div id="bannertext">
+ <img id="logo" alt="Apache Accumulo ™" src="/images/accumulo-logo.png"/>
+ </div>
+-->
+
+ <div id="content">
+
+ <h1 class="title">Apache Accumulo Git WIP</h1>
+
+ <p><a href="http://git-scm.com">Git</a> is an open source, distributed version control system
+which has become very popular in large, complicated software projects due to
+its efficient handling of multiple, simultaneously and independently developed
+branches of source code.\</p>
+<h2 id="workflow-background">Workflow Background</h2>
+<p>Likely the most contested subject matter regarding switching an active team
+from one SCM tool to another is a shift in the development paradigm.</p>
+<p>Some background, the common case, as is present with this team, is that
+developers coming from a Subversion history are very light on merging being a
+critical consideration on how to perform development. Because merging in
+Subversion is typically of no consequence to the complete view of history, not
+to mention that Subversion allows "merging" of specific revisions instead of
+sub-trees. As such, a transition to Git typically requires a shift in mindset
+in which a fix is not arbitrarily applied to trunk (whatever the main
+development is called), but the fix should be applied to the earliest, non
+end-of-life (EOL) version of the application.</p>
+<p>For example, say there is a hypothetical application which has just released
+version-3 of their software and have shifted their development to a version-4
+WIP. Version-2 is still supported, while version-1 was just EOL'ed. Each
+version still has a branch. A bug was just found which affects all released
+versions of this application. In Subversion, considering the history in the
+repository, it is of no consequence where the change is initially applied,
+because a Subversion merge is capable of merging it to any other version.
+History does not suffer because Subversion doesn't have the capacities to
+accurately track the change across multiple branches. In Git, to maintain a
+non-duplicative history, it is imperative that the developer choose the correct
+branch to fix the bug in. In this case, since version-1 is EOL'ed, version-2,
+version-3 and the WIP version-4 are candidates. The earliest version is
+obviously version-2; so, the change should be applied in version-2, merged to
+version-3 and then the version-4 WIP.</p>
+<p>The importance of this example is making a best-attempt to preserve history
+when using Git. While Git does have commands like cherry-pick which allow the
+contents of a commit to be applied from one branch to another which are not
+candidates to merge without conflict (which is typically the case when merging
+a higher version into a lower version), this results in a duplication of that
+commit in history when the two trees are eventually merged together. While Git
+is smart enough to not attempt to re-apply the changes, history still contains
+the blemish.</p>
+<p>The purpose of this extravagant example is to outline, in the trivial case, how
+the workflow decided upon for development is very important and has direct
+impact on the efficacy of the advanced commands bundled with Git.</p>
+<h2 id="proposed-workflow">Proposed Workflow</h2>
+<p>This is a summary of what has been agreed upon by vocal committers/PMC members
+on <a href="mailto:dev@accumulo.apache.org">dev@accumulo.apache.org</a>. Enumeration of
+every possible situation out of the scope of this document. This document
+intends to lay the ground work to define the correct course of action regardless
+of circumstances. Some concrete examples will be provided to ensure the
+explanation is clear.</p>
+<ol>
+<li>
+<p>Active development is performed concurrently over no less than two versions
+ of Apache Accumulo at any one point in time. As such, the workflow must
+ provide guidance on how and where changes should be made which apply to
+ multiple versions and how to ensure that such changes are contained in all
+ applicable versions.</p>
+</li>
+<li>
+<p>Releases are considered extremely onerous and time-consuming so no emphasis
+ is placed on rapid iterations or development-cycles.</p>
+</li>
+<li>
+<p>New features typically have lengthy development cycles in which more than
+ one developer contributes to the creation of the new feature from planning,
+ to implementation, to scale testing. Mechanisms/guidance should be provided
+ for multiple developers to teach contribute to a remote-shared resource.</p>
+</li>
+<li>
+<p>The repository should be the irrefutable, sole source of information
+ regarding the development of Apache Accumulo, and, as such, should have
+ best-efforts given in creating a clean, readable history without any single
+ entity having to control all write access and changes (a proxy). In other
+ words, the developers are the ones responsible for ensuring that previous
+ releases are preserved to meet ASF policy, for not rewriting any public
+ history of code not yet officially released (also ASF policy relevant) and
+ for a best-effort to be given to avoid duplicative commits appearing in
+ history created by the application of multiple revisions which have
+ different identifying attributes but the same contents (git-rebase and
+ git-cherry-pick).</p>
+</li>
+</ol>
+<h1 id="the-implementation">The implementation</h1>
+<h2 id="contributors">Contributors</h2>
+<p>Use the following steps, original derived from Apache Kafka's <a href="https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow">simple
+contributor
+workflow</a>.</p>
+<p>To be specific, let's consider a contributor wanting to work on a fix for the
+Jira issue ACCUMULO-12345 that affects 1.5.0 release.</p>
+<ol>
+<li>
+<p>Ensure you configured Git with your information</p>
+<p><code>git config --global user.name 'My Name' && git config --global user.email
+'myname@mydomain.com'</code></p>
+</li>
+<li>
+<p>Clone the Accumulo repository:</p>
+<p><code>git clone https://git-wip-us.apache.org/repos/asf/accumulo.git accumulo</code></p>
+</li>
+<li>
+<p>or update your local copy:</p>
+<p><code>git fetch && git fetch --tags</code></p>
+</li>
+<li>
+<p>For the given issue you intend to work on, choose the 'lowest' fixVersion
+ and create a branch for yourself to work in. This example is against the next release of 1.5</p>
+<p><code>git checkout -b ACCUMULO-12345-my-work origin/1.5</code></p>
+</li>
+<li>
+<p>Make commits as you see fit as you fix the issue, referencing the issue name
+ in the commit message:</p>
+<p><code>git commit -av</code></p>
+<p>Please include the ticket number at the beginning of the log message, and
+in the first line, as it's easier to parse quickly. For example:</p>
+<p><code>ACCUMULO-2428 throw exception when rename fails after compaction</code></p>
+<p>Consider following the git log message format described in
+<a href="http://zachholman.com/talk/more-git-and-github-secrets/">Zach Holman's talk</a>
+(specifically slides 78-98, beginning at 15:20 into the video). Essentially,
+leave a short descriptive message in the first line, skip a line, and write
+more detailed stuff there, if you need to. For example:</p>
+<p><code>ACCUMULO-2194 Add delay for randomwalk Security teardown</code></p>
+<p><code>If two Security randomwalk tests run back-to-back, the second test may see that the
+table user still exists even though it was removed when the first test was torn down.
+This can happen if the user drop does not propagate through Zookeeper quickly enough.
+This commit adds a delay to the end of the Security test to give ZK some time.</code></p>
+</li>
+<li>
+<p>Assuming others are developing against the version you also are, as you
+ work, or before you create your patch, rebase your branch against the remote
+ to lift your changes to the top of your branch. The branch specified here should be the same one you used in step 4.</p>
+<p><code>git pull --rebase origin 1.5</code></p>
+</li>
+<li>
+<p>At this point, you can create a patch file from the upstream branch to
+ attach to the ACCUMULO-12345 Jira issue. The branch specified here should be teh same one you used in step 4.</p>
+<p><code>git format-patch --stdout origin/1.5 > ACCUMULO-12345.patch</code></p>
+</li>
+</ol>
+<p>An alternative to creating a patch is submitting a request to pull your changes
+from some repository, e.g. Github. Please include the repository and branch
+name merge in the notice to the Jira issue, e.g.</p>
+<div class="codehilite"><pre><span class="n">repo</span><span class="p">=</span><span class="n">git</span><span class="p">:</span><span class="o">//</span><span class="n">github</span><span class="p">.</span><span class="n">com</span><span class="o">/<</span><span class="n">username</span><span class="o">>/</span><span class="n">accumulo</span><span class="p">.</span><span class="n">git</span> <span class="n">branch</span><span class="p">=</span><span class="n">ACCUMULO</span><span class="o">-</span>12345
+</pre></div>
+
+
+<p>A second alternative is to use Github's "Pull Requests" feature against the
+<a href="https://github.com/apache/accumulo">Apache Accumulo account</a>. Notifications of
+new pull-requests from Github should automatically be sent to
+<a href="mailto:dev@accumulo.apache.org">dev@accumulo.apache.org</a>.</p>
+<p>Ignoring specifics, contributors should be sure to make their changes against
+the earlier version in which the fix is intended, <code>git-rebase</code>'ing their
+changes against the upstream branch so as to keep their changes co-located and
+free of unnecessary merges.</p>
+<h2 id="developers">Developers</h2>
+<h3 id="primary-development">Primary Development</h3>
+<p>Primary development should take place in <code>master</code> which is to contain the most
+recent, un-released version of Apache Accumulo. Branches exist for minor releases
+for each previously released major version. </p>
+<p>Using long-lived branches that track a major release line simplifies management and
+release practices. Developers are encouraged to make branches for their own purposes,
+for large features, release candidates or whatever else is deemed useful.</p>
+<h3 id="reviewing-contributor-changes">Reviewing contributor changes</h3>
+<p>It is always the responsibility of committers to determine that a patch is
+intended and able to be contributed. From the
+<a href="http://www.apache.org/dev/new-committers-guide.html#cla">new committer's guide</a>:
+"Please take care to ensure that patches are original works which have been
+clearly contributed to the ASF in public. In the case of any doubt (or when a
+contribution with a more complex history is presented) please consult your
+project PMC before committing it."</p>
+<p>Extra diligence may be necessary when code is contributed via a pull request.
+Committers should verify that the contributor intended to submit the code as a
+Contribution under the <a href="http://www.apache.org/licenses/LICENSE-2.0.txt">Apache License</a>.
+When pulling the code, committers should also verify that the commits pulled match the
+list of commits sent to the Accumulo dev list in the pull request.</p>
+<h4 id="patches">Patches</h4>
+<p>Developers should use the following steps to apply patches from
+contributors:</p>
+<ol>
+<li>
+<p>Checkout the branch for the major version which the patch is intended:</p>
+<p><code>git checkout 1.5</code></p>
+</li>
+<li>
+<p>Verify the changes introduced by the patch:</p>
+<p><code>git apply --stat ACCUMULO-12345.patch</code></p>
+</li>
+<li>
+<p>Verify that the patch applies cleanly:</p>
+<p><code>git apply --check ACCUMULO-12345.patch</code></p>
+</li>
+<li>
+<p>If all is well, apply the patch:</p>
+<p><code>git am --signoff < ACCUMULO-12345.patch</code></p>
+</li>
+<li>
+<p>When finished, push the changes:</p>
+<p><code>git push origin 1.5</code></p>
+</li>
+<li>
+<p>Merge where appropriate:</p>
+<p><code>git checkout master && git merge 1.5</code></p>
+</li>
+</ol>
+<h4 id="github-pull-requests">Github Pull-Requests</h4>
+<p>If the contributor submits a repository and branch to pull
+from, the steps are even easier:</p>
+<ol>
+<li>
+<p>Add their repository as a remote to your repository</p>
+<p><code>git remote add some_name ${repository}</code></p>
+</li>
+<li>
+<p>Fetch the refs from the given repository</p>
+<p><code>git fetch ${repository}</code></p>
+</li>
+<li>
+<p>Merge in the given branch to your local branch</p>
+<p><code>git merge some_name/${branch}</code></p>
+</li>
+<li>
+<p>Delete the remote:</p>
+<p><code>git remote remove some_name</code></p>
+</li>
+</ol>
+<p>If the branch doesn't fast-forward merge, you likely want to inform the
+contributor to update their branch to avoid the conflict resolution and merge
+commit. See the <a href="http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging">Git
+manual</a>
+for more information on merging. When merging a pull-request, it's best to <strong>not</strong>
+include a signoff on the commit(s) as it changes the final commit ID in the
+Accumulo repository. This also has the negative of not automatically closing
+the Pull-Request when the changes are made public.</p>
+<h3 id="feature-branches">Feature Branches</h3>
+<p>Ease in creating and using feature branches is a desirable merit which Git
+provides with little work. Feature branches are a great way in which developers
+to work on multiple, long-running features concurrently, without worry of
+mixing code ready for public-review and code needing more internal work.
+Additionally, this creates an easily consumable series of commits in which
+other developers can track changes, and see how the feature itself evolved.</p>
+<p>To prevent developers' feature branches from colliding with one another, it was
+suggested to impose a "hierarchy" in which shared feature branches are prefixed
+with <code><apache_id>/ACCUMULO-<issue#>[-description]</code>.</p>
+<ol>
+<li>
+<p>Create a branch off of <code>master</code>.</p>
+<p><code>git checkout <apache_id>/ACCUMULO-<issue#> master</code></p>
+</li>
+<li>
+<p>Create the feature, commiting early and often to appropriately outline the
+"story" behind the feature and it's implementation.</p>
+</li>
+<li>
+<p>As long as you have not collaborating with others, <code>git-rebase</code> your feature
+branch against upstream changes in <code>master</code></p>
+<p><code>git fetch && git rebase origin/master</code></p>
+</li>
+<li>
+<p>If you are actively collaborating with others, you should be nice and not
+change their history. Use <code>git-merge</code> instead.</p>
+<p><code>git fetch && git merge origin/master</code></p>
+</li>
+<li>
+<p>Continue steps 2 through 4 until the feature is complete.</p>
+</li>
+<li>
+<p>Depending on the nature, duration and history of the changes in your feature
+branch, you can choose to:</p>
+<ul>
+<li>
+<p><strong>'Simple' Merge</strong>: </p>
+<p><code>git checkout master && git merge <apache_id>/ACCUMULO-<issue#></code></p>
+</li>
+<li>
+<p><strong>Rebase and merge</strong> -- keeps all feature-branch commits
+ co-located: </p>
+<p><code>git fetch && git rebase origin/master && git checkout master && git merge <apache_id>/ACCUMULO-<issue#></code></p>
+</li>
+<li>
+<p><strong>Merge with squash</strong> -- feature branch history is a mess, just make one commit
+ with the lump-sum of your feature branch changes: </p>
+<p><code>git checkout master && git merge --squash <apache_id>/ACCUMULO-<issue#></code></p>
+</li>
+</ul>
+</li>
+</ol>
+<h3 id="changes-which-affect-multiple-versions-aka-merging">Changes which affect multiple versions (a.k.a. merging)</h3>
+<p>Merging can be a very confusing topic for users switching to Git, but it can be
+summarized fairly easily.</p>
+<ol>
+<li>
+<p><strong>Precondition</strong>: choose the right branch to start! (lowest, applicable version
+ for the change)</p>
+</li>
+<li>
+<p>Get your changes fixed for that earliest version.</p>
+</li>
+<li>
+<p>Switch to the next highest version which future minor versions will be
+ released (non-EOL major release series).</p>
+</li>
+<li>
+<p><code>git-merge</code> the branch from #1 into the current.</p>
+</li>
+<li>
+<p>In the face of conflicts, use options from <code>git-merge</code> to help you.</p>
+<ul>
+<li><code>git checkout new-version && git merge --stat old-version</code></li>
+<li><code>git checkout new-version && git merge --no-commit old-version</code></li>
+</ul>
+</li>
+<li>
+<p>Treat your current branch as the branch from #2, and repeat from #2.</p>
+</li>
+</ol>
+<p>When merging changes across major releases, there is always the possibility of
+changes which are applicable/necessary in one release, but not in any future
+releases, changes which are different in implementation due to API changes, or
+any number of other cases. Whatever the actual case is, the developer who made
+the first set of changes (you) is the one responsible for performing the merge
+through the rest of the active versions. Even when the merge may results in a
+zero-length change in content, this is incredibly important to record as you
+are the one who knows that this zero-length change in content is correct!</p>
+<h2 id="release-management">Release Management</h2>
+<p>Releases, although not a day to day task, have their own unique steps which are
+to be followed. Releases can be categorized in to minor and major releases.</p>
+<h3 id="a-minor-release">A minor release</h3>
+<p>A minor release is some set of changes <code>z'</code> on top of a version <code>x.y.z</code>.
+Typically, <code>z'</code> is simply <code>z + 1</code>, e.g. given a release named '1.6.0', and the
+next minor release is '1.6.1'. These changes for <code>z'</code> should not break any
+client code which works against <code>z</code> and should absolutely not change the public
+API.</p>
+<p>By convention, the branch containing the changes <code>z'</code> should be named
+<code>x.y</code> (where the changes for <code>z'</code> are commits since <code>x.y.z</code>. The steps to take are as follows:</p>
+<ol>
+<li>Prepare the release candidate. <a href="/governance/releasing.html">Release
+ Guide</a>, <a href="/releasing.html">Maven
+ Instructions</a></li>
+<li>Create a branch for the release candidate from the <code>x.y</code> branch,
+ named something like <code>x.y.z'-RCN</code>.</li>
+<li>Test and Vote</li>
+<li>Create a GPG-signed tag with the correct final name: <code>x.y.z'</code></li>
+<li>Push a delete of the remote branch <code>x.y.z'-RCN</code></li>
+</ol>
+<p>This process is not firm and should not be viewed as requirements for making a release.
+The release manager is encouraged to make use branches/tags in whichever way is best.</p>
+<h3 id="a-major-release">A major release</h3>
+<p>A major release is a release in which multiple new features are introduced
+and/or the public API are modified. The major release <code>y'</code>, even when the
+client API is not modified, will typically contain many new features and
+functionality above the last release series <code>y</code>. A major release also resets
+the <code>z</code> value back to <code>0</code>.</p>
+<p>The steps to create a new major release are very similar to a minor release:</p>
+<ol>
+<li>Prepare the release candidate. <em>reference release instructions</em></li>
+<li>Create a tag of the release candidate from the <code>x.y</code> branch,
+ named something like <code>x.y.0-RCN</code>.</li>
+<li>Test and Vote</li>
+<li>Create a GPG-signed tag with the correct final name: <code>x.y.0</code></li>
+<li>Push a delete of the remote branch <code>x.y.0-RCN</code></li>
+</ol>
+<h1 id="the-infrastructure">The infrastructure</h1>
+<p>This section deals with the changes that must be requested through INFRA. As
+with any substantial INFRA request, the VOTE and result from the mailing should
+be referenced so INFRA knows that the request has been acknowledged. Likely, a
+PMC member should be the one to submit the request.</p>
+<h2 id="repositories">Repositories</h2>
+<p>I believe that we will need multiple repositories to best align ourselves with
+how we currently track "Accumulo" projects. The repositories follow:</p>
+<ol>
+<li>
+<p>The main source tree. This will track the standard trunk, branches, tags
+ structure from Subversion for Apache Accumulo.</p>
+</li>
+<li>
+<p>One repository for every project in
+ <a href="https://svn.apache.org/repos/asf/accumulo/contrib">contrib</a>: Accumulo-BSP,
+ Instamo Archetype, and the Wikisearch project. Each of these
+ are considered disjoint from one another, and the main source tree, so they
+ each deserve their own repository.</p>
+</li>
+</ol>
+<p>Given the list of repositories that currently exist on the <a href="https://git-wip-us.apache.org/repos/asf">ASF
+site</a> and a brief search over INFRA
+tickets, multiple repositories for a single Apache project is not an issue.
+Having this list when making the initial ticket will likely reduce the amount
+of work necessary in opening multiple INFRA tickets.</p>
+<h2 id="mirroring">Mirroring</h2>
+<p>It should be noted in the INFRA requst that each repository will also need to
+be configured to properly mirror to the <a href="https://github.com/apache">ASF Github</a>
+account to provide the same functionality with current have via the git+svn
+mirror. This should be noted in the INFRA request. Same change needs to be
+applied for the <a href="http://git.apache.org">Apache hosted</a> mirror'ing.</p>
+<h2 id="mailing-lists">Mailing lists</h2>
+<p>It should be noted in the INFRA request that commit messages should be sent to
+<a href="mailto:commits@accumulo.apache.org">commits@accumulo.apache.org</a>. The subject
+can be decided on using the <a href="https://git-wip-us.apache.org/docs/switching-to-git.html#contents">provided
+variables</a>.</p>
+<h1 id="examples">Examples</h1>
+<p>For the sake of clarity, some examples of common situations are included below.</p>
+<h2 id="releasing-160">Releasing 1.6.0</h2>
+<ol>
+<li>
+<p>Branch from <code>master</code> to <code>1.6</code></p>
+<p><code>git checkout master && git branch 1.6</code></p>
+</li>
+<li>
+<p>Tag <code>1.6.0-RC1</code> from the just created <code>1.6</code> branch</p>
+<p><code>git tag 1.6.0-RC1 1.6</code></p>
+</li>
+<li>
+<p>Test, vote, etc. and tag from 1.6.0-RC1</p>
+<p><code>git -s tag 1.6.0 1.6.0-RC1</code></p>
+</li>
+<li>
+<p>Delete the RC tag, if desired.</p>
+<p><code>git tag -d 1.6.0-RC1 && git push --delete origin 1.6.0-RC1</code></p>
+</li>
+<li>
+<p>Ensure <code>master</code> contains all features and fixes from <code>1.6.0</code></p>
+<p><code>git checkout master && git merge 1.6</code></p>
+</li>
+<li>
+<p>Update the project version in <code>master</code> to 1.7.0-SNAPSHOT</p>
+</li>
+</ol>
+ </div>
+
+ <div id="footer">
+ <a alt="Apache Software Foundation" href="http://www.apache.org">
+ <img id="asf-logo" alt="Apache Software Foundation" src="/images/feather-small.gif" width="100">
+ </a>
+ <div class="copyright">
+ <p>
+ Copyright © 2011-2014 The Apache Software Foundation, Licensed under
+ the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.
+ Apache Accumulo, Accumulo, Apache, the Apache feather logo, and the Apache Accumulo
+ project logo are trademarks of the <a href="http://www.apache.org">Apache Software Foundation</a>.<br />
+ Site created with <a href="http://getbootstrap.com/">Bootstrap</a> including icons from <a href="http://glyphicons.com/">GLYPHICONS</a> and <a href="http://fontawesome.io/">Font Awesome</a>.
+ </p>
+ </div>
+ </div>
+ </div>
+
+</div>
+</div>
+
+<script type="text/javascript">
+
+$("#nav_git").addClass("active");
+
+</script>
+</body>
+</html>