accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1490109 - in /accumulo/site/branches/git/content: css/accumulo.css git.mdtext
Date Thu, 06 Jun 2013 01:47:21 GMT
Author: elserj
Date: Thu Jun  6 01:47:21 2013
New Revision: 1490109

ACCUMULO-1498 First draft at infrastructure and implementation (sans release management) taken
primarily from suggestions on the mailaing list.


Modified: accumulo/site/branches/git/content/css/accumulo.css
--- accumulo/site/branches/git/content/css/accumulo.css (original)
+++ accumulo/site/branches/git/content/css/accumulo.css Thu Jun  6 01:47:21 2013
@@ -61,7 +61,8 @@ h1, h2, h3, h4, h5, h6 {
 #content h1 {
     font-size: 1.4em;
-    padding: 15px;
+    padding-top: 15px;
+    padding-bottom: 15px;
 #content h2 {
     border-bottom: 1px dashed #666666;

Modified: accumulo/site/branches/git/content/git.mdtext
--- accumulo/site/branches/git/content/git.mdtext (original)
+++ accumulo/site/branches/git/content/git.mdtext Thu Jun  6 01:47:21 2013
@@ -16,14 +16,14 @@ Notice:    Licensed to the Apache Softwa
            specific language governing permissions and limitations
            under the License.
-## Git
+# Git
 [Git]( 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 brances
 of source code.
-## The plan
+# The plan
 There are multiple steps that are required of us to fully transition from active
 development against Subversion to Git. Each of these requires consensus (lazy or
@@ -31,7 +31,7 @@ not) from the team along with documentat
 current, can reference to understand how and what to do.
-### Workflow Background
+## Workflow Background
 Likely the most contested subject matter regarding switching an active team from
 one SCM tool to another is a shift in the development paradigm.
@@ -74,7 +74,7 @@ The purpose of this extravagant example 
 the workflow decided upon for development is very important and has direct
 impact on the efficacy of the advanced commands bundled with Git.
-### Proposed Workflow
+## Proposed Workflow
 I'll try to summarize what has thus far been agreed upon by vocal
 committers/PMC members on I will attempt to refer to
@@ -105,22 +105,80 @@ best-effort to be given to avoid duplica
 created by the application of multiple revisions which have different
 identifying attributes but the same contents (git-rebase and git-cherry-pick).
-## The implementation 
+# The implementation 
-### Contributors
+## Contributors
-### Developers
+Follow the [simple contributor
+from Apache Kafka's website.
-### Release Management
+In a nutshell, contributors should make their changes against the version in
+which the fix is intended, `git-rebase`'ing their changes against the upstream
+branch so as to keep their changes co-located and free of unnecessary merges.
-## The infrastructure
+The final contribution can be in the form of a git formatted patch (see the
+Kafka workflow linked above), a request to pull changes from a remote+ref, or a
+pull-request from [Apache Accumulo
+on Github]( Pull-requests from Github should
+automatically be sent to [](
+## Developers
+### Primary Development
+Primary development should take place in a single branch which contains the most
+recent, un-released version of Apache Accumulo. The name of such branch is up
+for debate -- `master`, `development` or `unstable` are all reasonable names for
+such a branch and developers must make a decision.
+For changes staged for the next minor release of Apache Accumulo, it has been
+suggested that a branch is created for the purpose of containing the bug-fixes,
+API-compatible improvements and backported-features. This provides the following:
+1. Avoids many long-running 'SNAPSHOT' branches to force the developer to best
+   consider where his/her changes should be applied.
+2. Better ties a branch containing commits for a minor release to Jira issues
+   fixed in said minor release.
+3. Others that I'm not thinking of? I think more exist in gigantic 'GIT' thread
+   on dev@a.a.o.
+If said short-lived branch doesn't yet exist, the developer should create said
+branch off of the last minor release in the targeted major version.
+For example, if a developer finds a fix that needs to be made against the 1.4.3
+release of Apache Accumulo, the developer should create a new branch from the
+1.4.3 tag, apply the changes, and push the branch remotely with an appropriate
+name. It has been suggested to name the branch in the same manner in which Maven
+releases are named. In other words, the branch just created would be named
+`1.4.4-snapshot` or similar.
+### Feature Branches
+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.
+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 `feature/${USERNAME}/${JIRA_ISSUE}-description`. This is another decision
+that requires input from all developers who care.
+## Release Management
+# The infrastructure
 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.
-### Repositories
+## Repositories
 I believe that we will need multiple repositories to best align ourselves with
 how we currently track "Accumulo" projects. The repositories follow:
@@ -140,7 +198,7 @@ tickets, multiple repositories for a sin
 Having this list when making the initial ticket will likely reduce the amount of
 work necessary in opening multiple INFRA tickets.
-### Mirroring
+## Mirroring
 It should be noted in the INFRA requst that each repository will also need to be
 configured to properly mirror to the [ASF Github](
@@ -148,7 +206,7 @@ account to provide the same functionalit
 mirror. This should be noted in the INFRA request. Same change needs to be
 applied for the [Apache hosted]( mirror'ing.
-### Mailing lists
+## Mailing lists
 It should be noted in the INFRA request that commit messages should be sent to
 []( The subject

View raw message