diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..675198c
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,32 @@
+
+
+# Contributing to the Accumulo Website
+
+Contributions to the website can be made by creating pull requests to this repo on GitHub.
+
+Before creating a pull request, follow the instructions in the [README.md] to test
+your changes by running the website locally.
+
+If you cannot run the website locally, it's OK to submit your pull request. A committer
+will test your changes before merging.
+
+For general information on contributing to Accumulo projects, check out the
+[How To Contribute][contribute] page.
+
+[README.md]: README.md
+[contribute]: https://accumulo.apache.org/how-to-contribute/
diff --git a/README.md b/README.md
index ec88309..56f0bab 100644
--- a/README.md
+++ b/README.md
@@ -5,6 +5,10 @@ use [Bundler] to install the necessary dependencies to run and build the website
## Install Bundler and dependencies
+Ruby is required to use Bundler so first make sure you have Ruby on your machine. If you are using
+an OS packaged version of Ruby, you will have to also install the ruby-dev (Ubuntu) or
+ruby-devel (Fedora) package as well.
+
With Ruby installed on your machine, you can install [Bundler] using the command below:
gem install bundler
diff --git a/blog/2014/05/03/accumulo-classloader.html b/blog/2014/05/03/accumulo-classloader.html
index c8d7720..72bded2 100644
--- a/blog/2014/05/03/accumulo-classloader.html
+++ b/blog/2014/05/03/accumulo-classloader.html
@@ -99,6 +99,7 @@
All Accumulo mailing lists are in the accumulo.apache.org domain. Please note
-that search providers linked on this page are not part of the official Apache
-mailing list archives.
+
Below are ways to get in touch with the Apache Accumulo community.
+
+
Issues
+
+
Accumulo uses JIRA to track bugs and new features. Before creating an issue, you will need to create
+an Apache JIRA account.
+
+
Mailing Lists
+
+
The Accumulo mailing lists are for general discussions, questions, and announcements. While you can read the archives
+using the links below, it’s best to subscribe to the user and dev (if you contribute) mailing lists to
+follow discussions as they happen.
Contributions to Apache Accumulo are welcome! If you are interested, read how to contribute. If you need help finding something to work on, send a message to our dev mailing list and we’ll help you find a task that interests you.
This page contains resources and documentation for Accumulo contributors. Any documentation that is helpful
-to Accumulo users should go in the Accumulo User Manual.
+ Click here if you are not redirected.
+
diff --git a/contributor/lazyConsensus.html b/contributor/lazyConsensus.html
index 8e0cf0e..5750591 100644
--- a/contributor/lazyConsensus.html
+++ b/contributor/lazyConsensus.html
@@ -99,6 +99,7 @@
@@ -156,7 +156,9 @@ be used to support development in the context of the
Contributors to Accumulo are encouraged to use RB for non-trivial patches and
any time feedback is desired. No one is required to use RB, but its ready
availability and better interface for feedback can help with reviews. Committers
-seeking review prior to pushing changes can also benefit similarly.
+seeking review prior to pushing changes can also benefit similarly. It should
+be noted that more recently the use of GitHub has been overtaking the use of
+Review Board for code reviews.
Roles for Review Board
diff --git a/contributor/versioning.html b/contributor/release-management.html
similarity index 53%
copy from contributor/versioning.html
copy to contributor/release-management.html
index dbfa00d..3ac3fe2 100644
--- a/contributor/versioning.html
+++ b/contributor/release-management.html
@@ -25,7 +25,7 @@
-Versioning
+Release Management
@@ -99,6 +99,7 @@
The Apache Accumulo PMC closed a vote on 2014/12/12 which adopted Semantic Versioning 2.0.0 as
-the reference document on the meaning and requirements of the versions of Apache Accumulo. Semantic
-versioning requires a definition of a public API: this definition is unchanged over previous releases and
-can be found in section 9 of the README. A copy of the specification is included here, licensed under
-Creative Commons - CC BY 3.0:
+
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
-
Specification
+
A minor release
-
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
-in this document are to be interpreted as described in RFC 2119.
+
A minor release is some set of changes z' on top of a version x.y.z.
+Typically, z' is simply z + 1, e.g. given a release named ‘1.6.0’, and the
+next minor release is ‘1.6.1’. These changes for z' should not break any
+client code which works against z and should absolutely not change the public
+API.
+
+
By convention, the branch containing the changes z' should be named
+x.y (where the changes for z' are commits since x.y.z. The steps to take are as follows:
Create a branch for the release candidate from the x.y branch,
+named something like x.y.z'-RCN.
+
Test and Vote
+
Create a GPG-signed tag with the correct final name: x.y.z'
+
Push a delete of the remote branch x.y.z'-RCN
+
+
+
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.
+
+
A major release
+
+
A major release is a release in which multiple new features are introduced
+and/or the public API are modified. The major release y', even when the
+client API is not modified, will typically contain many new features and
+functionality above the last release series y. A major release also resets
+the z value back to 0.
+
+
The steps to create a new major release are very similar to a minor release:
Create a tag of the release candidate from the x.y branch,
+named something like x.y.0-RCN.
+
Test and Vote
+
Create a GPG-signed tag with the correct final name: x.y.0
+
Push a delete of the remote branch x.y.0-RCN
+
+
+
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
+
+
I believe that we will need multiple repositories to best align ourselves with
+how we currently track “Accumulo” projects. The repositories follow:
-
Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist
-strictly in documentation. However it is done, it should be precise and comprehensive.
-
-
-
A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain
-leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase
-numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
-
-
-
Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST
-be released as a new version.
-
-
-
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be
-considered stable.
+
The main source tree. This will track the standard trunk, branches, tags
+structure from Subversion for Apache Accumulo.
-
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent
-on this public API and how it changes.
+
One repository for every project in
+contrib: 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.
+
+
+
Given the list of repositories that currently exist on the ASF
+site 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.
+
+
Mirroring
+
+
It should be noted in the INFRA request that each repository will also need to
+be configured to properly mirror to the ASF Github
+account to provide the same functionality with current have via the git+svn
+mirror. Same change needs to be applied for the Apache hosted
+mirror’ing.
For the sake of clarity, some examples of common situations are included below.
+
+
Releasing 1.6.0
+
+
-
Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix
-is defined as an internal change that fixes incorrect behavior.
+
Branch from master to 1.6
+
+
git checkout master && git branch 1.6
-
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the
-public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if
-substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes.
-Patch version MUST be reset to 0 when minor version is incremented.
+
Tag 1.6.0-RC1 from the just created 1.6 branch
+
+
git tag 1.6.0-RC1 1.6
-
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public
-API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.
+
Test, vote, etc. and tag from 1.6.0-RC1
+
+
git -s tag 1.6.0 1.6.0-RC1
-
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following
-the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty.
-Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal
-version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements
-as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
+
Delete the RC tag, if desired.
+
+
git tag -d 1.6.0-RC1 && git push --delete origin 1.6.0-RC1
-
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following
-the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST
-NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the
-build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
+
Ensure master contains all features and fixes from 1.6.0
+
+
git checkout master && git merge 1.6
-
Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating
-the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence).
-Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major,
-minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. When major, minor, and patch
-are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0. Precedence for two
-pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier
-from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and
-identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence
-than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the
-preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 <
-1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
+
Update the project version in master to 1.7.0-SNAPSHOT
Accumulo has a number of contrib projects that maintain their own code repositories and release schedules.
-
-
Project Website
-
-
The source for this website is a collection of markdown documents that are converted to HTML using
-Jekyll. It can be found in the accumulo-website repo. If you would like to make changes to
-this website, clone the website repo and edit the markdown:
After you have made your changes, follow the instructions in the README.md to run the website
-locally and make a pull request on GitHub. If you have problems installing Jekyll or running the
-website locally, it’s OK to proceed with the pull request. A committer will review your changes before committing
-them and updating the website.
-
-
Developer’s Guide
-
-
Building
-
-
Installing Apache Thrift
-
-
If you activate the ‘thrift’ Maven profile, the build of some modules will attempt to run the Apache Thrift command line to regenerate
-stubs. If you activate this profile and don’t have Apache Thrift installed and in your path, you will see a warning and
-your build will fail. For Accumulo 1.5.0 and greater, install Thrift 0.9 and make sure that the ‘thrift’ command is in your path.
-Watch out for THRIFT-1367; you may need to configure Thrift with –without-ruby. Most developers do not
-need to install or modify the Thrift definitions as a part of developing against Apache Accumulo.
Accumulo uses Apache Maven to handle source building, testing, and packaging. To build Accumulo, you will need to use Maven version 3.0.5 or later.
-
-
You should familiarize yourself with the Maven Build Lifecycle, as well as the various plugins we use in our POM, in order to understand how Maven works and how to use the various build options while building Accumulo.
-
-
To build from source (for example, to deploy):
-
-
mvn package -Passemble
-
-
-
-
This will create a file accumulo-*-SNAPSHOT-dist.tar.gz in the assemble/target directory. Optionally, append -DskipTests if you want to skip the build tests.
-
-
To build your branch before submitting a pull request, you’ll probably want to run some basic “sunny-day” integration tests to ensure you haven’t made any grave errors, as well as checkstyle and findbugs:
-
-
mvn verify -Psunny
-
-
-
-
To run specific unit tests, you can run:
-
-
mvn package -Dtest=MyTest -DfailIfNoTests=false
-
-
-
-
Or to run the specific integration tests MyIT and YourIT (and skip all unit tests), you can run:
There are plenty of other options. For example, you can skip findbugs with mvn verify -Dfindbugs.skip or checkstyle -Dcheckstyle.skip, or control the number of forks to use while executing tests, -DforkCount=4, etc. You should check with specific plugins to see which command-line options are available to control their behavior. Note that not all options will result in a [...]
-
-
If you regularly switch between major development branches, you may receive errors about improperly licensed files from the RAT plugin. This is caused by modules that exist in one branch and not the other leaving Maven build files that the RAT plugin no longer understands how to ignore.
-
-
The easiest fix is to ensure all of your current changes are stored in git and then cleaning your workspace.
Note that this git clean command will delete any files unknown to git in a way that is irreversible. You should check that no important files will be included by first looking at the “untracked files” section in a git status command.
-
-
$> git status
-# On branch master
-nothing to commit (working directory clean)
-$> mvn package
-{ maven output elided }
-$> git checkout 1.6.1-SNAPSHOT
-Switched to branch '1.6.1-SNAPSHOT'
-$> git status
-# On branch 1.6.1-SNAPSHOT
-# Untracked files:
-# (use "git add <file>..." to include in what will be committed)
-#
-# mapreduce/
-# shell/
-nothing added to commit but untracked files present (use "git add" to track)
-$> git clean -df
-Removing mapreduce/
-Removing shell/
-$> git status
-# On branch 1.6.1-SNAPSHOT
-nothing to commit (working directory clean)
-
Import Formatter: Preferences > Java > Code Style > Formatter and import the Eclipse-Accumulo-Codestyle.xml downloaded in the previous step.
-
Import Template: Preferences > Java > Code Style > Code Templates and import the Eclipse-Accumulo-Template.xml. Make sure to check the “Automatically add comments” box. This template adds the ASF header and so on for new code.
-
-
-
IntelliJ
-
-
-
Formatter plugin that uses eclipse code style xml.
Git is an open source, distributed version control system
+
This page contains resources and documentation of interest to current and potential contributors to the Accumulo project. Any documentation that is helpful to Accumulo users should go in the Accumulo User Manual.
+
+
If your are interested in quickly getting an Accumulo instance up and running, see the Accumulo Quickstart guides (1.x)/(2.x) or refer to the Uno project on Github.
Apache Accumulo welcomes contributions from the community. This is especially true of new contributors! You don’t need to be a software developer to contribute to Apache Accumulo. So, if you want to get involved in Apache Accumulo, there is almost certainly a role for you. View our How to Contribute page for additional details on the many opportunities available.
+
+
Project Resources
+
+
Accumulo makes use of the following external tools for development.
+
+
GitHub
+
+
Apache Accumulo® source code is maintained using Git version control and mirrored to GitHub. Source files can be browsed here or at the GitHub mirror.
+
+
The project code can be checked-out here. It builds with Apache Maven.
+
+
JIRA
+
+
Accumulo tracks issues with JIRA. Prospective code contributors can view open issues labeled for “newbies” to search for starter tickets. Note that every commit should reference a JIRA ticket of the form ACCUMULO-#.
+
+
Jenkins/TravisCI
+
+
Accumulo uses Jenkins and TravisCI for automatic builds and continuous integration.
If you run into a bug or think there is something that would benefit the project, we encourage you to file an issue at the Apache Accumulo JIRA page. Regardless of whether you have the time to provide the fix or implementation yourself, this will be helpful to the project.
+
+
Building Accumulo from Source
+
+
Installing Apache Thrift
+
+
If you activate the ‘thrift’ Maven profile, the build of some modules will attempt to run the Apache Thrift command line to regenerate
+stubs. If you activate this profile and don’t have Apache Thrift installed and in your path, you will see a warning and
+your build will fail. For Accumulo 1.5.0 and greater, install Thrift 0.9 and make sure that the ‘thrift’ command is in your path.
+Watch out for THRIFT-1367; you may need to configure Thrift with –without-ruby. Most developers do not
+need to install or modify the Thrift definitions as a part of developing against Apache Accumulo.
+
+
Checking out from Git
+
+
There are several methods for obtaining the Accumulo source code. If you prefer to use SSH rather than HTTPS you can refer to the GitHub help pages for help in creating a GitHub account and setting up SSH keys.
+
+
- from your Github Fork
+
+
It is also possible to fork a repository in GitHub so that you can freely experiment with changes without affecting the original project. You can then submit a pull request from your personal fork to the project repository when you wish to supply a contribution.
Accumulo uses Apache Maven to handle source building, testing, and packaging. To build Accumulo, you will need to use Maven version 3.0.5 or later.
+
+
You should familiarize yourself with the Maven Build Lifecycle, as well as the various plugins we use in our POM, in order to understand how Maven works and how to use the various build options while building Accumulo.
+
+
To build from source (for example, to deploy):
+
+
mvn package -Passemble
+
+
+
+
This will create a file accumulo-*-SNAPSHOT-dist.tar.gz in the assemble/target directory. Optionally, append -DskipTests if you want to skip the build tests.
+
+
To build your branch before submitting a pull request, you’ll probably want to run some basic “sunny-day” integration tests to ensure you haven’t made any grave errors, as well as checkstyle and findbugs:
+
+
mvn verify -Psunny
+
+
+
+
To run specific unit tests, you can run:
+
+
mvn package -Dtest=MyTest -DfailIfNoTests=false
+
+
+
+
Or to run the specific integration tests MyIT and YourIT (and skip all unit tests), you can run:
There are plenty of other options. For example, you can skip findbugs with mvn verify -Dfindbugs.skip or checkstyle -Dcheckstyle.skip, or control the number of forks to use while executing tests, -DforkCount=4, etc. You should check with specific plugins to see which command-line options are available to control their behavior. Note that not all options will result in a [...]
+
+
If you regularly switch between major development branches, you may receive errors about improperly licensed files from the RAT plugin. This is caused by modules that exist in one branch and not the other leaving Maven build files that the RAT plugin no longer understands how to ignore.
+
+
The easiest fix is to ensure all of your current changes are stored in git and then cleaning your workspace.
Note that this git clean command will delete any files unknown to git in a way that is irreversible. You should check that no important files will be included by first looking at the “untracked files” section in a git status command.
+
+
$> git status
+# On branch master
+nothing to commit (working directory clean)
+$> mvn package
+{ maven output elided }
+$> git checkout 1.6.1-SNAPSHOT
+Switched to branch '1.6.1-SNAPSHOT'
+$> git status
+# On branch 1.6.1-SNAPSHOT
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+# mapreduce/
+# shell/
+nothing added to commit but untracked files present (use "git add" to track)
+$> git clean -df
+Removing mapreduce/
+Removing shell/
+$> git status
+# On branch 1.6.1-SNAPSHOT
+nothing to commit (working directory clean)
+
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
branches of source code.
-
Workflow Background
+
Workflow Background
The most likely contested subject matter regarding switching an active team
from one SCM tool to another is a shift in the development paradigm.
@@ -196,7 +404,7 @@ the blemish.
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
This is a summary of what has been agreed upon by vocal committers/PMC members
on dev@accumulo.apache.org. Enumeration of
@@ -238,16 +446,15 @@ for a best-effort to be given to avoid duplicative commits appearing in
-
The implementation
+
The Implementation
-
Contributors
+
The following steps, originally derived from Apache kafka’s
+simple contributor workflow, will demonstrate the gitflow implementation.
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
+and create a branch for yourself to work in. This example is against the next release of 1.8
-
git checkout -b ACCUMULO-12345-my-work origin/1.5
+
git checkout -b ACCUMULO-12345-my-work origin/1.8
Make commits as you see fit as you fix the issue, referencing the issue name
@@ -288,31 +495,36 @@ in the commit message:
(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:
+
+
-
ACCUMULO-2194 Add delay for randomwalk Security teardown
+
ACCUMULO-2194 Add delay for randomwalk Security teardown
-
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.
-
+ 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.
+
+
+
+
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.
-
git pull --rebase origin 1.5
+
git pull --rebase origin 1.8
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.
+attach to the ACCUMULO-12345 Jira issue. The branch specified here should be the same one you used in step 4.
-
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
+from some repository, e.g. GitHub. Please include the repository and branch
name merge in the notice to the Jira issue, e.g.
repo=git://github.com/<username>/accumulo.git branch=ACCUMULO-12345
@@ -329,9 +541,9 @@ the earlier version in which the fix is intended, Developers
+
Developers
-
Primary Development
+
Primary Development
Primary development should take place in master which is to contain the most
recent, un-released version of Apache Accumulo. Branches exist for minor releases
@@ -341,7 +553,7 @@ for each previously released major version.
release practices. Developers are encouraged to make branches for their own purposes,
for large features, release candidates or whatever else is deemed useful.
-
Reviewing contributor changes
+
Reviewing contributor changes
It is always the responsibility of committers to determine that a patch is
intended and able to be contributed. From the
@@ -357,7 +569,7 @@ Contribution under the
-
Checkout the branch for the major version which the patch is intended:
-
git checkout 1.5
+
git checkout 1.8
Verify the changes introduced by the patch:
@@ -386,16 +598,16 @@ contributors:
When finished, push the changes:
-
git push origin 1.5
+
git push origin 1.8
Merge where appropriate:
-
git checkout master && git merge 1.5
+
git checkout master && git merge 1.8
-
Github Pull-Requests
+
Submit Contribution via Pull-Request
If the contributor submits a repository and branch to pull
from, the steps are even easier:
@@ -432,7 +644,7 @@ include a signoff on the commit(s) as it changes the final commit ID in the
Accumulo repository. This also has the negative effect of not automatically closing
the Pull-Request when the changes are made public.
-
Feature Branches
+
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
@@ -496,7 +708,7 @@ with the lump-sum of your feature branch changes:
-
Changes which affect multiple versions (a.k.a. merging)
+
Changes which affect multiple versions (a.k.a. merging)
Merging can be a very confusing topic for users switching to Git, but it can be
summarized fairly easily.
@@ -538,136 +750,98 @@ 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!
-
Release Management
-
-
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.
-
-
A minor release
+
Code review process
-
A minor release is some set of changes z' on top of a version x.y.z.
-Typically, z' is simply z + 1, e.g. given a release named ‘1.6.0’, and the
-next minor release is ‘1.6.1’. These changes for z' should not break any
-client code which works against z and should absolutely not change the public
-API.
+
Accumulo primarily uses GitHub (via pull requests) for code reviews, but has access to an instance of Review Board as well if that is preferred.
-
By convention, the branch containing the changes z' should be named
-x.y (where the changes for z' are commits since x.y.z. The steps to take are as follows:
+
Accumulo operates under the Commit-Then-Review (CtR) policy, so a code review does not need to occur prior to commit. However, a commiter has the option to hold a code review before a commit happens if, in their opinion, it would benefit from additional attention. Full details of the code review process for Accumulo is documented here
Create a branch for the release candidate from the x.y branch,
-named something like x.y.z'-RCN.
-
Test and Vote
-
Create a GPG-signed tag with the correct final name: x.y.z'
-
Push a delete of the remote branch x.y.z'-RCN
-
+
Review Board
-
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.
+
Use of Review Board has slowly diminished and been gradually replaced by GitHub reviews over the past year or so.
-
A major release
+
Additional Contributor Information
-
A major release is a release in which multiple new features are introduced
-and/or the public API are modified. The major release y', even when the
-client API is not modified, will typically contain many new features and
-functionality above the last release series y. A major release also resets
-the z value back to 0.
+
Coding Practices
-
The steps to create a new major release are very similar to a minor release:
Create a tag of the release candidate from the x.y branch,
-named something like x.y.0-RCN.
-
Test and Vote
-
Create a GPG-signed tag with the correct final name: x.y.0
-
Push a delete of the remote branch x.y.0-RCN
-
+
+
+
+
License Header
+
Always add the current ASF license header as described in [ASF Source Header][srcheaders].
+
+
+
Trailing Whitespaces
+
Remove all trailing whitespaces. Eclipse users can use Source→Cleanup option to accomplish this.
+
+
+
Indentation
+
Use 2 space indents and never use tabs!
+
+
+
Line Wrapping
+
Use 160-column line width for Java code and Javadoc.
+
+
+
Control Structure New Lines
+
Use a new line with single statement if/else blocks.
+
+
+
Author Tags
+
Do not use Author Tags. The code is developed and owned by the community.
+
+
+
-
The infrastructure
+
Merging Practices
-
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.
+
Changes should be merged from earlier branches of Accumulo to later branches. Ask the dev list for instructions.
-
Repositories
+
Project Examples
-
I believe that we will need multiple repositories to best align ourselves with
-how we currently track “Accumulo” projects. The repositories follow:
The main source tree. This will track the standard trunk, branches, tags
-structure from Subversion for Apache Accumulo.
-
-
-
One repository for every project in
-contrib: 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.
-
-
+
Website Contributions
-
Given the list of repositories that currently exist on the ASF
-site 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.
+
The source for this website is a collection of markdown documents that are converted to HTML using
+Jekyll. It can be found in the accumulo-website repo. If you would like to make changes to this website, clone the website repo and edit the markdown:
It should be noted in the INFRA request that each repository will also need to
-be configured to properly mirror to the ASF Github
-account to provide the same functionality with current have via the git+svn
-mirror. Same change needs to be applied for the Apache hosted
-mirror’ing.
+
After you have made your changes, follow the instructions in the README.md to run the website locally and make a pull request on GitHub. If you have problems installing Jekyll or running the website locally, it’s OK to proceed with the pull request. A committer will review your changes before committing them and updating the website.
Refer to the README in the release you are using to see what packages are in the public API.
-
Examples
+
Changes to non-private members of those classes are subject to additional scrutiny to minimize compatibility problems across Accumulo versions.
-
For the sake of clarity, some examples of common situations are included below.
+
Installing Apache Thrift
-
Releasing 1.6.0
+
If you activate the ‘thrift’ Maven profile, the build of some modules will attempt to run the Apache Thrift command line to regenerate stubs. If you activate this profile and don’t have Apache Thrift installed and in your path, you will see a warning and your build will fail. For Accumulo 1.5.0 and greater, install Thrift 0.9 and make sure that the ‘thrift’ command is in your path. Watch out for THRIFT-1367; you may need to configure Thrift with –without-ruby. Most developers do not n [...]
-
-
-
Branch from master to 1.6
+
Committer Documentation
-
git checkout master && git branch 1.6
-
-
-
Tag 1.6.0-RC1 from the just created 1.6 branch
+
The links below are provided primarily for the project committers but may be of interest to contributors as well.
You don’t need to be a software developer to contribute to
-Apache Accumulo. To be successful, this project
-requires a huge range of different skills, levels of involvement, and degrees of
-technical expertise. So, if you want to get involved in Apache Accumulo, there
-is almost certainly a role for you.
-
-
We are looking for people to:
-
-
-
provide feedback
-
write or update documentation
-
help new users
-
recommend the project to others
-
test the code and report bugs
-
fix bugs
-
give us feedback on required features
-
write and update the software
-
create artwork
-
translate to different languages
-
anything you can see that needs doing
-
-
-
All of these contributions help to keep the project active and strengthen
-the community. The project team and the broader community will
-therefore welcome and encourage participation, and attempt to make it
-as easy as possible for people to get involved.
-
-
Want to get started now? Check out open issues labeled for “newbies”. If you need help, use the mailing list information below to reach out. If the issue you choose deals with code, you should read the developer’s guide section.
-
-
Mailing lists and chat
-
-
Your first engagement with the project should be to subscribe to our
-mailing lists. Apache Accumulo developers and community members
-hang out in the #accumulo channel on irc.freenode.net.
-
-
Contributor Guide
-
-
See the contributor guide for recommended practices in interacting with our source code.
-Take a look at Accumulo’s OpenHub page for an analysis of the code base.
The most important thing about engaging with any Apache project is that everyone
-is equal. All people with an opinion are entitled to express that opinion and, where
-appropriate, have it considered by the community.
-
-
To some, the idea of having to establish consensus in a large and distributed team
-sounds inefficient and frustrating. Don’t despair though, The Apache Way has a
-set of simple processes to ensure things proceed at a good pace.
-
-
In ASF projects we don’t like to vote. We reserve that for the few things that need
-official approval for legal or process reasons (e.g. a release or a new committer).
-Most of the time we work with the consensus building techniques documented below.
-
-
Lazy Consensus
-
-
Lazy consensus is the first, and possibly the most important, consensus building
-tool we have. Essentially, lazy consensus means that you don’t need to get explicit
-approval to proceed, but you need to be prepared to listen if someone objects.
-
-
Consensus Building
-
-
Sometimes, lazy consensus is not appropriate. In such cases, it is necessary to
-make a proposal to the mailing list and discuss options. There are mechanisms
-for quickly showing your support or otherwise for a proposal and
-building consensus amongst the community.
-
-
Once there is a consensus, people can proceed with the work under the lazy
-consensus model.
-
-
Voting
-
-
Occasionally a “feel” for consensus is not enough. Sometimes we need to
-have a measurable consensus. For example, when voting in new committers or
-to approve a release.
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+ Redirecting…
+
+
+
Redirecting…
+ Click here if you are not redirected.
+
diff --git a/git.html b/git.html
deleted file mode 100644
index 5bdc7ea..0000000
--- a/git.html
+++ /dev/null
@@ -1,10 +0,0 @@
-
-
-
- Redirecting…
-
-
-
Redirecting…
- Click here if you are not redirected.
-
-
diff --git a/glossary/index.html b/glossary/index.html
index 12b063c..6d93f52 100644
--- a/glossary/index.html
+++ b/glossary/index.html
@@ -99,6 +99,7 @@
Contributions are welcome to all Apache Accumulo repositories. While most contributions are code,
+there are other ways to contribute to Accumulo:
+
+
+
answer questions on mailing lists
+
review pull requests
+
verify and test new releases
+
update the Accumulo website and documentation
+
+
+
Contributions are reviewed (via GitHub pull requests) by
+the community before being merged by a committer.
+
+
This document provides basic instructions for contributing to Accumulo. If you are looking for more information, check out the more comprehensive contributor guide.
+
+
Issues
+
+
Any contribution should have a corresponding issue. Accumulo uses JIRA for issue tracking. Before creating an issue,
+you will need to create an Apache JIRA account. If you need help finding an issue to work on, check out
+the open issues labeled for newbies or contact us.
+
+
Repositories
+
+
Contributions can be made to the following repositories. While the general contribution workflow is
+described below, repositories have special instructions in their CONTRIBUTING.md file which can be
+viewed by clicking on contribute in the Links column below.
Create a Pull Request on GitHub to the appropriate repository. If the work is not complete and the Pull Request is for feedback, please put [WIP] in the subject.
+
At least one committer (and others in the community) will review your pull request and add any comments to your code.
+
Push any changes from the review to the branch as new commits so the reviewer only needs to review new changes. Please avoid squashing commits after the review starts. Squashing makes it hard for the reviewer to follow the changes.
+
Repeat this process until a reviewer approves the pull request.
+
When the review process is finished, all commits on the pull request may be squashed by a committer. Please avoid squashing as it makes it difficult for the committer to know if they are merging what was reviewed.
+
+
+
Coding Guidelines
+
+
+
If a change needs to go into multiple branches of Accumulo, it should be merged into earlier branches then later branches.
+
Accumulo follows semver for its public API. Accumulo lists which packages are public API in its README.md.
+
Every file requires the ASF license header as described in ASF Source Header.
+
Remove all trailing whitespaces. Eclipse users can use Source→Cleanup option to accomplish this.
+
Use 2 space indents and never use tabs!
+
Use 160-column line width for Java code and Javadoc.
+
Use a new line with single statement if/else blocks.
+
Do not use Author Tags. The code is developed and owned by the community.
+
+
+
Code Editors
+
+
Feel free to use any editor when contributing Accumulo. If you are looking for a recommendation, many Accumulo
+developers use IntelliJ or Eclipse. Below are some basic instructions to help you get started.
Import the repository as a Maven project into Eclipse
+
(Optional) Download and import Eclipse formatting and style guides from Accumulo’s contrib directory
+
+
Import Formatter: Preferences > Java > Code Style > Formatter and import the Eclipse-Accumulo-Codestyle.xml downloaded in the previous step.
+
Import Template: Preferences > Java > Code Style > Code Templates and import the Eclipse-Accumulo-Template.xml. Make sure to check the “Automatically add comments” box. This template adds the ASF header and so on for new code.
All Accumulo mailing lists are in the accumulo.apache.org domain. Please note
-that search providers linked on this page are not part of the official Apache
-mailing list archives.
+ Click here if you are not redirected.
+
diff --git a/news/index.html b/news/index.html
index 945e812..45fb9a1 100644
--- a/news/index.html
+++ b/news/index.html
@@ -99,6 +99,7 @@
This example shows how to use Accumulo to store a file system history. It has three classes:
+
Installing Accumulo
-
-
Ingest.java - Recursively lists the files and directories under a given path, ingests their names and file info (not the file data!) into an Accumulo table, and indexes the file names in a separate table.
-
QueryUtil.java - Provides utility methods for getting the info for a file, listing the contents of a directory, and performing single wild card searches on file or directory names.
-
Viewer.java - Provides a GUI for browsing the file system information stored in Accumulo.
-
FileCountMR.java - Runs MR over the file system information and writes out counts to an Accumulo table.
-
FileCount.java - Accomplishes the same thing as FileCountMR, but in a different way. Computes recursive counts and stores them back into table.
-
StringArraySummation.java - Aggregates counts for the FileCountMR reducer.
-
-
-
To begin, ingest some data with Ingest.java.
+
This document covers installing Accumulo on single and multi-node environments. Either download or build a binary distribution of Accumulo from source code. Unpack as follows:
cd <install_location>
+tar xzf <some_dir>/accumulo-X.Y.Z-bin.tar.gz
+cd accumulo-X.Y.Z
-
Note that running this example will create tables direxample and dirindex in Accumulo that you should delete when you have completed the example.
-If you modify a file or add new files in the directory ingested (e.g. /local/user1/workspace), you can run Ingest again to add new information into the Accumulo tables.
+
Accumulo has some optional native code that improves its performance and stability. Before configuring Accumulo attempt to build this native code with the following command.
-
To browse the data ingested, use Viewer.java. Be sure to give the “username” user the authorizations to see the data.
To perform searches on file or directory names, also use QueryUtil.java. Search terms must contain no more than one wild card and cannot contain “/”.
-Note these queries run on the dirindex table instead of the direxample table.
+
The Accumulo conf directory needs to be populated with initial config files. The following script is provided to assist with this. Run the script and answer the questions. When the script ask about memory-map type, choose Native if the build native script was successful. Otherwise choose Java.
To count the number of direct children (directories and files) and descendants (children and children’s descendents, directories and files), run the FileCountMR over the direxample table.
-The results can be written back to the same table.
+
The script will prompt for memory usage. Please note that the footprints are only for the Accumulo system processes, so ample space should be left for other processes like hadoop, zookeeper, and the accumulo client code. If Accumulo worker processes are swapped out and unresponsive, they may be killed.
After this script runs, the conf directory should be populated and now a few edits are needed.
+
+
Secret
+
+
Accumulo coordination and worker processes can only communicate with each other if they share the same secret key. To change the secret key set instance.secret in conf/accumulo-site.xml. Changing this secret key from the default is highly recommended.
+
+
Dependencies
+
+
Accumulo requires running Zookeeper and HDFS instances. Also, the Accumulo binary distribution does not include jars for Zookeeper and Hadoop. When configuring Accumulo the following information about these dependencies must be provided.
+
+
+
Location of Zookeepers : Provide this by setting instance.zookeeper.host in conf/accumulo-site.xml.
+
Where to store data : Provide this by setting instance.volumes in conf/accumulo-site.xml. If your namenode is running at 192.168.1.9:9000 and you want to store data in /accumulo in HDFS, then set instance.volumes to hdfs://192.168.1.9:9000/accumulo.
+
Location of Zoookeeper and Hadoop jars : Setting ZOOKEEPER_HOME and HADOOP_PREFIX in conf/accumulo-env.sh will help Accumulo find these jars.
+
+
+
If Accumulo has problems later on finding jars, then run bin/accumulo classpath to print out info about where Accumulo is finding jars. If the settings mentioned above are correct, then inspect general.classpaths in conf/accumulo-site.xml.
+
+
Initialization
+
+
Accumulo needs to initialize the locations where it stores data in Zookeeper and HDFS. The following command will do this.
+
+
./bin/accumulo init
+
+
The initialization command will prompt for the following information:
+
+
+
Instance name : This is the name of the Accumulo instance and its Accumulo clients need to know it inorder to connect.
+
Root password : Initialization sets up an initial Accumulo root user and prompts for its password. This information will be needed to later connect to Accumulo.
+
+
+
Multiple Nodes
+
+
Skip this section if running Accumulo on a single node. Accumulo has coordinating, monitoring, and worker processes that run on specified nodes in the cluster. The following files should be populated with a newline separated list of node names. Must change from localhost.
+
+
+
conf/masters : Accumulo primary coordinating process. Must specify one node. Can specify a few for fault tolerance.
+
conf/gc : Accumulo garbage collector. Must specify one node. Can specify a few for fault tolerance.
+
conf/monitor : Node where Accumulo monitoring web server is run.
+
conf/slaves : Accumulo worker processes. List all of the nodes where tablet servers should run in this file.
+
conf/tracers : Optional capability. Can specify zero or more nodes.
+
+
+
The Accumulo, Hadoop, and Zookeeper software should be present at the same location on every node. Also the files in the conf directory must be copied to every node. There are many ways to replicate the software and configuration, two possible tools that can help replicate software and/or config are pdcp and prsync.
+
+
Starting Accumulo
+
+
The Accumulo scripts use ssh to start processes on remote nodes. Before attempting to start Accumulo, passwordless ssh must be setup on the cluster.
+
+
After configuring and initializing Accumulo, use the following command to start it.
+
+
./bin/start-all.sh
+
+
First steps
+
+
Once the start-all.sh script completes, use the following command to run the Accumulo shell.
+
+
./bin/accumulo shell -u root
+
+
Use your web browser to connect the Accumulo monitor page on port 9995.
+
+
http://<hostname in conf/monitor>:9995/
+
+
When finished, use the following command to stop Accumulo.
+ Click here if you are not redirected.
+
+
diff --git a/release/accumulo-1.5.1/index.html b/release/accumulo-1.5.1/index.html
index 9e7f73b..7242914 100644
--- a/release/accumulo-1.5.1/index.html
+++ b/release/accumulo-1.5.1/index.html
@@ -99,6 +99,7 @@