Author: elserj
Date: Thu Jun 6 01:47:21 2013
New Revision: 1490109
URL: http://svn.apache.org/r1490109
Log:
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/git.mdtext
Modified: accumulo/site/branches/git/content/css/accumulo.css
URL:
http://svn.apache.org/viewvc/accumulo/site/branches/git/content/css/accumulo.css?rev=1490109&r1=1490108&r2=1490109&view=diff
==============================================================================
--- 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
URL:
http://svn.apache.org/viewvc/accumulo/site/branches/git/content/git.mdtext?rev=1490109&r1=1490108&r2=1490109&view=diff
==============================================================================
--- 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](http://git-scm.com) 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 [email protected]. 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
+workflow](https://cwiki.apache.org/confluence/display/KAFKA/Git+Workflow#GitWorkflow-Simplecontributorworkflow)
+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](https://github.com/apache/accumulo). Pull-requests from Github
should
+automatically be sent to
[[email protected]](mailto:[email protected]).
+
+## 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 [email protected].
+
+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
+
+_TODO_
+
+# 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](https://github.com/apache)
@@ -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](http://git.apache.org) mirror'ing.
-### Mailing lists
+## Mailing lists
It should be noted in the INFRA request that commit messages should be sent to
[[email protected]](mailto:[email protected]). The subject
