http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71ede83/rb.md ---------------------------------------------------------------------- diff --git a/rb.md b/rb.md deleted file mode 100644 index 4213fe2..0000000 --- a/rb.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: Using Review Board ---- - -The Apache Software Foundation provides an [instance][rbinstance] of -[Review Board][rb] (RB) for projects to use in code reviews. Here is how RB can -be used to support development in the context of the -[Apache Accumulo bylaws][bylaws]. - -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. - -## Roles for Review Board - -### Optional Pre-Commit Review - -Accumulo operates under the [Commit-Then-Review][ctr] (CtR) policy, so code -review does not need to occur prior to commit. However, a committer may opt to -hold a code review before commit for changes that, in their opinion, would -benefit from additional attention. RB can be used to conduct such code reviews. - -### Consensus Approval after a Code Change Veto - -Code changes are approved by lazy approval, with consensus approval following -a veto (see the [Actions][actions] section of the bylaws). RB can be used -to coordinate a consensus approval vote by providing a convenient view of the -code change under consideration. The vote itself must still be held on the -developer mailing list. - -## Guidelines for Posting a Review - -* It is best to post a git-generated patch as the basis for a review. RB does - not support patches containing multiple commits, so either squash commits - first, or submit a diff spanning the changeset. The `rbt` and `post-review` - tools generate diffs. -* Strive to make your changes small. Reviewers are less likely to want to - trudge through a review with lots of changes, and are more likely to miss - problems. -* Begin the summary of the review with a JIRA issue number. A review must - always be associated with a JIRA issue. The issue number should also be - entered in the "Bugs" field of the review, providing a link to JIRA. -* The "Branch" field should contain the name of the branch that the code change - is based on (e.g., the base of your git feature branch). -* Include the "accumulo" user group as reviewers. Also include specific people - as individual reviewers, even if they are in the "accumulo" group, if you - deem them of primary importance for the review (e.g., you have been working - out problems with the review with them, they are expert in the area). -* Use the description to summarize the change under review. Include helpful - instructions to the reviewers here. -* Describe any testing done on the change. It is not expected that reviewers - will do their own testing, and they may reject the review if you have not - done sufficient testing yourself. -* Avoid submitting generated code for review if it can be reproduced by a - reviewer. - -After the review is published, set the status of the associated JIRA issue to -"Patch Available" as a signal to reviewers. Also, link to the review from the -issue (More -> Link -> Web Link) to help viewers of the issue find the review -and assess its progress. - -## Guidelines for Reviewing Code - -* Try to associate comments with relevant lines of code in the review. -* By default, each comment opens a review issue. If a comment pertains to - something that should not block the review from completing successfully, then - clear the "Open an issue" checkbox before saving your feedback. Examples that - might qualify as non-issues: minor formatting/whitespace issues, spelling - mistakes, general background questions. -* If a review looks good, be sure to "Ship It" by either using the "Ship It!" - button or by submitting a general review with the "Ship It" checkbox checked. - -## Guidelines for Completing a Review - -These guidelines do not apply to consensus approval votes, since the vote -completion depends on the votes registered in the developer mailing list. - -* Use your judgement for the number of "Ship It"s you want to receive to - consider a review passed. Usually, getting one "Ship It" is enough to proceed - with a commit. It is recommended that the "Ship It" be from a committer who - is a neutral party not involved in the change under review. -* Use your judgement for the minimum time length you set for the review. Simple - changes can be up for just a day, while complex ones should take up to seven. -* Review time should be extended in the face of problems discovered in the - review. Update the review with improved code instead of discarding (i.e., - closing unsuccessfully) it and beginning a new one. -* A review should not be "submitted" (i.e., closed successfully) unless there - are no outstanding issues. Check with reviewers to ensure that their issues - are resolved satisfactorily. -* A review should be "discarded" if the code requires major rework or it - becomes obvious it should never be committed (due to design changes, - becoming overcome by events, being back-burnered, etc.). -* Don't leave a review open indefinitely. Once you have received sufficient - feedback to submit or discard it, do so. If there has been no activity for - some time, discard the review. A new one can always be created later. - -Once you've closed a review as submitted, if you are unable to commit your -changes yourself, attach the final version of them to the relevant JIRA issue. -They should be in the form of a patch containing a single commit, -[per the final steps of the contribution process][contributor]. - -[rbinstance]: https://reviews.apache.org -[rb]: https://www.reviewboard.org -[bylaws]: {{ site.baseurl }}/bylaws -[ctr]: https://www.apache.org/foundation/glossary#CommitThenReview -[actions]: {{ site.baseurl }}/bylaws#actions -[contributor]: {{ site.baseurl }}/git#contributors
http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71ede83/releasing.md ---------------------------------------------------------------------- diff --git a/releasing.md b/releasing.md deleted file mode 100644 index 4e36968..0000000 --- a/releasing.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: Making a Release ---- - -This is a guide for the creation of a release of Apache Accumulo. - -## Setup - -There are number of things that are required before attempting to build a release. - -1. Use gpg-agent, and be sure to increase the gpg-agent cache timeout (via .gnupg/gpg-agent.conf) to ensure that the agent doesn't require re-authentication mid-build, as it will cause things to fail. For example, you can add `default-cache-ttl 6000` to increase the timeout from the default of 10 minutes to over an hour. If you do not have a GPG key, reference the very thorough [ASF release signing documentation][1]. -2. Ensure that you're using the correct major release of Java (check javadoc too). -3. Ensure that you're building Apache Accumulo with a username that has the same name as your Apache ID (this is due to - the maven-release-plugin and staging the release candidate). -4. Update the CHANGES file so that it's in sync with Jira (manual process). -5. Ensure that you have a texlive distribution installed so you are able to build the documentation. -6. Have a clean workspace before starting. - -Given all of this, it's recommended that you only attempt making a release from a GNU/Linux machine. - -## Create the candidate - -**TL;DR** - -* `./assemble/build.sh --create-release-candidate` to make the release candidate -* `git tag $version $version-rcN` to create an RC tag from the actual tag -* `git tag -d $version` make sure you don't accidentally push a "release" tag -* `git push origin $version-rcN` push the RC tag -* `git checkout -b $version-rcN-branch` save off the branch from the Maven release plugin -* **VOTE** -* *If vote fails*, fix the original branch and start over. -* *If vote passes*, `git merge $version-rcN-branch` back into the original branch you released from. -* `git tag -s $version-rcN $version` make a GPG-signed tag -* `git push origin $version` push the signed tag. - -**Long-winded explanation** - -You should use the provided script assemble/build.sh to create the release candidate. This script is -desirable as it activates all necessary maven profiles in addition to verifying that certain preconditions -are met, like RPM signing availablilty and the ability to sign files using GPG. The --test option can -be used as a dry run for creating a release candidate. The --create-release-candidate option should be -used to create the actual release candidate. - -When invoking build.sh with the --create-release-candidate option, the majority of the work will be performed -by the maven-release-plugin, invoking *release:clean*, *release:prepare*, and *release:perform*. These will -guide you through choosing the correct versions. The default options provided should be what you choose. -It is highly recommended that an 'RC' suffix is *not* appended to the release version the plugin prompts -you for, as that will result in that version string being placed into the poms, which then would require -voting to occur on artifacts that cannot be directly promoted. After the build.sh script finishes (this will -likely take at least 15 minutes, even on recent hardware), your current branch will be on the "next" version -that you provided to the release plugin. - -One unwanted side-effect of this approach is that after creating this branch, but *before invoking release:perform*, -you must edit the release.properties to add the _-rcN_ suffix to the value of scm.tag. Otherwise, the release -plugin will complain that it cannot find the branch for the release. With a successful invocation of *mvn release:perform*, -a staging repository will be made for you on the [ASF Nexus server][2] which you can log into with your ASF -credentials. - -After you log into Nexus, click on _Staging Repositories_ in the _Build Promotion_ toolbar on the left side of -the screen. Assuming your build went according to plan, you should have a new staging repository made for -you. At this point, you should inspect the artifacts that were staged to ensure that they are as you expect -them to be. When you're ready to present those artifacts for voting, you need to close that repository which -will make it publicly available for other members to inspect. - -## Vote - -At this point, you should have a closed repository that's ready to vote on. Send a message to [the dev -list](mailto:[email protected]) and get the ball rolling. If the vote ultimately fails, you delete -the staged repository, clean up the branch you created (or wait until the release ultimately passes if you -choose), and fix what needs fixing. - -If the vote passes, huzzah, you're almost done. - -## Promote the artifacts - -Promote that staged repository using Nexus which you can do with the click of a button. This will trigger -a process to get the release out to all of the mirrors. - -## Create the final Git tag - -The Git repository should also contain a tag which refers to the final commit which made up a release. This tag -should also be signed with your GPG key. To ensure proper retention on release (stemming from ASF policy -requirements), This final tag *must* being with "rel/". For example, a release of 1.7.0 should have a corresponding -tag name of "rel/1.7.0". - - -## Copy artifacts to dist.apache.org - -An SVN server is running at https://dist.apache.org/repos/dist/release/accumulo. You need to upload the release -tarballs, the GPG signatures and checksum files to the correct directory (based on the release number). If you -are releasing a bug-fix release, be sure to delete the previous release in the same line (e.g. if you release -1.6.2, remove 1.6.1). The old tarballs removed from dist.apache.org will still be preserved in archive.apache.org -automatically. - -## Update projects.apache.org - -Fill out the [add release][addrelease] form to update the projects website. - -## Update the Website - -After a successful vote, this website needs to be updated with the new artifacts. - - * Copy Accumulo User Manual (HTML version exists in >=1.7.0) - * Update downloads page - * Create release notes (ensure notes contain link to JIRA changes for that version) - * Remove previous bug-fix release (if applicable) - * Update examples README files - * Update doap_Accumulo.rdf - -### Javadocs - -Javadocs are easy to update. Using the latest JDK7 or later (at least JDK 7u21 -to avoid known [vulnerabilities][7]), follow these steps: - -1. Unpack the source release tarball and change to its root directory, or checkout the SCM tag for the release -2. Build the javadocs with `mvn clean package javadoc:aggregate -DskipTests -Paggregate-javadocs` -3. Take note that the javadocs you will need to copy are the entire contents of `./target/site/apidocs/` -4. Checkout the `gh-pages` branch (you may need to move the contents of `./target/site/apidocs` outside your git workspace to switch branches) -5. Remove any existing apidocs from the appropriate version folder (e.g. 1.6/apidocs for a 1.6.x release) -6. Copy the entire contents of the new apidocs directory (identified in step 3) to the destination (e.g. to 1.6/apidocs) -7. Continue updating the site content, as needed -8. Commit the changes -9. Update the site using jekyll with `./_devtools/git-hooks/post-commit` (if you don't have the commit hook already configured) -10. Don't forget to push both the `gh-pages` and `asf-site` branches -11. Verify that javadocs have been updated on the production site (e.g. https://accumulo.apache.org/1.6/apidocs/) - -## References - -Some good references that explain a few things: - -- [Christopher talks about making releases][3] -- [Publishing Maven Artifacts][4] -- [Publishing Releases][5] -- [Accumulo Release Guide][6] - - -[1]: https://www.apache.org/dev/release-signing -[2]: https://repository.apache.org -[3]: https://mail-archives.apache.org/mod_mbox/accumulo-dev/201305.mbox/raw/%3CCAL5zq9bH8y0FyjXmmfXhWPj8axosn9dZ7%2Bu-R1DK4Y-WM1YoWg%40mail.gmail.com%3E -[4]: https://www.apache.org/dev/publishing-maven-artifacts -[5]: https://www.apache.org/dev/release-publishing -[6]: {{ site.baseurl }}/governance/releasing -[7]: https://www.kb.cert.org/vuls/id/225657 -[8]: https://www.apache.org/dev/cmsref#extpaths -[addrelease]: https://reporter.apache.org/addrelease?accumulo http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71ede83/screenshots.md ---------------------------------------------------------------------- diff --git a/screenshots.md b/screenshots.md deleted file mode 100644 index 4de0fb0..0000000 --- a/screenshots.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Screenshots ---- - -<div class="row"> -<div class="col-xs-3"> -The following is a screenshot of the Apache Accumulo™ monitor overview web page. Accumulo was running on an eleven node cluster. The continuous ingest test suite was running to generate load. Ten continuous ingest clients were running. -</div> -<div class="col-xs-9"> -<a class="thumbnail" href="{{ site.baseurl }}/images/overview2.png"> -<img src="{{ site.baseurl }}/images/overview2.png" alt="monitor overview"/> -</a> -</div> -</div> - -<div class="row"> -<div class="col-xs-3"> -The following screenshot shows the monitor master page. This page gives information about individual tables within accumulo. Continuous ingest is running against the table ci. -</div> -<div class="col-xs-9"> -<a class="thumbnail" href="{{ site.baseurl }}/images/master2.png"> -<img src="{{ site.baseurl }}/images/master2.png" alt="monitor master"/> -</a> -</div> -</div> - -The data generated by the continuous ingest test suite looks like the following. The data is random, but forms many giant linked list. Each ingest client continually generates linked list containing 25 million nodes. In the shell session below a few scans are issued to start following the linked list that the first node in the table is part of. - - root@test15 ci> scan - 000000000135fbbe 074c:569c [] 2db1de18-cd37-407d-b060-481a0a214c90:000000002b2bcfe1:2e15cb9f62fd22ab:fe6f84c7 - 000000000d76dcc9 4f62:0647 [] 65f401e8-4f93-498c-bffa-ecc21a8645fd:000000000e7c2bbc:6fad98d023b8f146:a2c4d59f - 0000000024e07be4 5e56:221d [] 5283b4bd-4f18-4af9-a242-c8053b095e04:000000001e1ad441:12de1d82f4a7bf2f:ae231a6a - 000000003e13cb50 1d0a:415c [] 5944afab-8407-4391-9994-91b313e545dd:0000000002d61c91:4890a8885e54b714:d542fafa - 00000000634d0aaa 310d:1e58 [] 2db1de18-cd37-407d-b060-481a0a214c90:000000000c9e8018:4111345bc9afe2bb:4cbfd774 - 000000007d378414 08d2:0066 [] 15ab8578-faae-4ebb-9827-26728be78476:0000000052de5aac:06202f405c60726d:8ad4911a - 000000008c3615d8 3868:5f66 [] 8f47568c-a383-4910-83c9-36b75ac66440:0000000067faf572:750d567f3dd0c5bf:5ea938fe - 0000000090be2a77 7f32:2ca4 [] 8f47568c-a383-4910-83c9-36b75ac66440:000000005912be62:47ac0c7bb89013f1:dff13db9 - 00000000a7ca8e58 360f:5763 [] a9f5e129-e260-4a0e-a763-c6e3ef7b3eb6:0000000030bff255:37c8226225c804ba:665f261f - 00000000f1000713 5079:46bd [] 30af7f48-15ae-4ccb-81c9-4662ad74be92:0000000014d408e3:56a9dec63aed4d8f:0f2a44ec - 000000017e3ca989 56ac:062b [] 30af7f48-15ae-4ccb-81c9-4662ad74be92:000000000a8926a1:0bd54c769871aa78:b8e61d77 - --------------------------------------- hit any key to continue or 'q' to quit ----------------------------------------- - root@test15 ci> scan -b 2e15cb9f62fd22ab -e 2e15cb9f62fd22ab - 2e15cb9f62fd22ab 1fc1:1486 [] 2db1de18-cd37-407d-b060-481a0a214c90:000000002b1c8da1:53a9e4ba97e4a6e0:4a8bd624 - root@test15 ci> scan -b 53a9e4ba97e4a6e0 -e 53a9e4ba97e4a6e0 - 53a9e4ba97e4a6e0 37f3:33a2 [] 2db1de18-cd37-407d-b060-481a0a214c90:000000002b0d4b61:1c16a4ae1bef9f1f:f03c869b - root@test15 ci> scan -b 1c16a4ae1bef9f1f -e 1c16a4ae1bef9f1f - 1c16a4ae1bef9f1f 07c8:7cd3 [] 2db1de18-cd37-407d-b060-481a0a214c90:000000002afe0921:2e3ec09a8d2fdf52:8b82be48 http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71ede83/source.md ---------------------------------------------------------------------- diff --git a/source.md b/source.md deleted file mode 100644 index e40c597..0000000 --- a/source.md +++ /dev/null @@ -1,234 +0,0 @@ ---- -title: Source Code and Developers Guide -skiph1fortitle: true ---- - -<div class="panel panel-default pull-right"> -<div class="panel-heading">Quick Links</div> -<div class="list-group"> -<a href="https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=summary"; class="list-group-item"><i class="fa fa-external-link"></i> Accumulo source</a> -<a href="https://builds.apache.org/job/Accumulo-Master"; class="list-group-item"><i class="fa fa-external-link"></i> Master build on Jenkins</a> -<a href="https://issues.apache.org/jira/browse/ACCUMULO"; class="list-group-item"><i class="fa fa-external-link"></i> Accumulo JIRA</a> -</div> -</div> - -## Source Code - -### Apache Accumulo - -Apache Accumulo™ source code is maintained using [Git][git] version control -([browse][cgit]|[checkout][anongit]). It builds with [Apache Maven][maven]. - -Instructions for configuring git are [here][git-instr]. - -### Contrib Projects - -Accumulo has a number of [contrib projects][contrib] that maintain their own code repositories and release schedules. - -### Website - -Accumulo's web site is developed using [Jekyll][jekyll]. Development is -performed by editing the contents of the [gh-pages][gh-pages] branch, either -directly by a committer, with a pull request to [GitHub][github], or a patch -submitted to [JIRA][jiraloc]. The rendered site can be previewed locally or on -[GitHub][site-mirror], and the rendered site (in the `_site` directory) will be -merged into the `asf-site` branch to update our [official/canonical -site][site-canon] after being built. - -To manage any Gem dependencies, it is highly recommended to use [Bundler](https://bundler.io). -To start using Bundler, install it and then the dependencies for the website: - - gem install bundler - bundle install - -To get help with jekyll: - - jekyll help - -To test the site locally (usually on http://localhost:4000): - - jekyll serve --safe - -To do the same with Bundler: - - bundle exec jekyll serve --safe - -To build for updating the `asf-site` branch: - - jekyll build --safe - -To do the same with Bundler: - - bundle exec jekyll build --safe - -For preview convenience and consistent builds and testing, build using a -version which looks the same locally and on GitHub. - -A [post-commit hook][hook] is available for you to automatically create a -commit in the `asf-site` branch locally each time you commit to the `gh-pages` -branch. You can also run this command manually: - - ./_devtools/git-hooks/post-commit - -To automatically run this post-commit hook in your local repository, copy -the given file into your `.git/hook` directory: - - cp ./_devtools/git-hooks/post-commit .git/hooks/ - -## 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. - -#### Checking out from Git - -To check out the code: - - git clone https://git-wip-us.apache.org/repos/asf/accumulo.git - -#### Running a Build - -Accumulo uses [Apache Maven][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][lifecycle], as well as the various plugins we use in our [POM][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: - - mvn verify -Dtest=NoSuchTestExists -Dit.test=MyIT,YourIT -DfailIfNoTests=false - -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 stable build, and options may change over time. - -If you regularly switch between major development branches, you may receive errors about improperly licensed files from the [RAT plugin][1]. 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. - - $> git add path/to/file/that/has/changed - $> git add path/to/other/file - $> git clean -df - -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) - -### Continuous Integration - -Accumulo uses [Jenkins][jenkins] for automatic builds. - -<img src="https://builds.apache.org/job/Accumulo-Master/lastBuild/buildStatus"; style="height: 1.1em"> [Master][masterbuild] - -<img src="https://builds.apache.org/job/Accumulo-1.7/lastBuild/buildStatus"; style="height: 1.1em"> [1.7 Branch][17build] - -<img src="https://builds.apache.org/job/Accumulo-1.6/lastBuild/buildStatus"; style="height: 1.1em"> [1.6 Branch][16build] - -### Issue Tracking - -Accumulo [tracks issues][jiraloc] with [JIRA][jira]. Every commit should reference a JIRA ticket of the form ACCUMULO-#. - -### Merging Practices - -Changes should be merged from earlier branches of Accumulo to later branches. Ask the [dev list][devlist] for instructions. - -### Public API - -Refer to the README in the release you are using to see what packages are in the public API. - -Changes to non-private members of those classes are subject to additional scrutiny to minimize compatibility problems across Accumulo versions. - -### Coding Practices - -{: .table} -| **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. | - -### Code Review - -Accumulo has [guidelines for using Review Board][rb] to support code reviews. - -### IDE Configuration Tips - -#### Eclipse - -* Download Eclipse [formatting and style guides for Accumulo][styles]. -* 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][intellij-formatter] that uses eclipse code style xml. - -### Release Guide - -Accumulo's release guide can be found [here][release]. - -[16build]: https://builds.apache.org/job/Accumulo-1.6 -[17build]: https://builds.apache.org/job/Accumulo-1.7 -[1]: https://creadur.apache.org/rat/apache-rat-plugin -[anongit]: git://git.apache.org/accumulo.git -[cgit]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=summary -[contrib]: contrib -[devlist]: mailto:[email protected] -[gh-pages]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=tree;h=gh-pages -[git-instr]: https://git-wip-us.apache.org -[git]: https://git-scm.com -[github]: https://github.com/apache/accumulo -[hook]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=_devtools/git-hooks/post-commit;hb=gh-pages -[intellij-formatter]: https://code.google.com/p/eclipse-code-formatter-intellij-plugin -[jekyll]: https://jekyllrb.com -[jenkins]: https://jenkins.io -[jira]: https://www.atlassian.com/software/jira -[jiraloc]: https://issues.apache.org/jira/browse/ACCUMULO -[lifecycle]: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle -[masterbuild]: https://builds.apache.org/job/Accumulo-Master -[maven]: https://maven.apache.org -[pom]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob_plain;f=pom.xml;hb=HEAD -[rb]: rb -[release]: governance/releasing -[site-canon]: https://accumulo.apache.org -[site-mirror]: http://apache.github.io/accumulo -[srcheaders]: https://www.apache.org/legal/src-headers -[styles]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=tree;f=contrib;hb=HEAD http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71ede83/thanks.md ---------------------------------------------------------------------- diff --git a/thanks.md b/thanks.md deleted file mode 100644 index 1972275..0000000 --- a/thanks.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Thanks ---- - -First off, thanks to our parent organization, the [Apache Software Foundation][ASF] and [all who sponsor][ASF_SPONSORS] them. - -Additionally, we would like to thank the following organizations for resources that they provide: - - - ej-technologies for allowing us to use their [Java profiler][JPROFILER] - - YourKit for allowing us use of their [Java Profiler][YOURKIT] - - Coverity for running [static analysis][COVERITY] - -[ASF]: https://www.apache.org -[ASF_SPONSORS]: https://www.apache.org/foundation/sponsorship -[JPROFILER]: https://www.ej-technologies.com/products/jprofiler/overview.html -[YOURKIT]: https://www.yourkit.com/java/profiler/features/ -[COVERITY]: https://scan.coverity.com/projects/accumulo - http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71ede83/verifying_releases.md ---------------------------------------------------------------------- diff --git a/verifying_releases.md b/verifying_releases.md deleted file mode 100644 index ed04412..0000000 --- a/verifying_releases.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Verifying a Release ---- - -This is a guide for the verification of a release candidate of Apache Accumulo. These steps are meant to encapsulate -the requirements of the PMC set forth by the Foundation itself. - -The information here is meant to be an application of Foundation policy. When in doubt or conflict, any Foundation-level -trumps anything written here. - -Verification of a release candidate can be broken down into three categories. - -## Accumulo Correctness ## - -Testing a distributed database is, arguably, the easiest of these requirements. - -Accumulo contains unit and integration tests which can be automatically run via Maven. These tests can be invoked -by issues the following commands: - - $ mvn verify - -Additionally, Accumulo contains multiple distributed tests, most notably the RandomWalk and ContinuousIngest tests. -Information on these tests can be found in their respective directories, `test/system/randomwalk` and - `test/system/continuous`, which include instructions on how to run the tests. These tests are intended to be run -for days on end while injecting faults into the system. These are the tests that truly verify the correctness of -Accumulo on real systems. - -More information on these tests, and the requirements in running them for a given release, can be found on the -[governance page on releasing][1] - -## Foundation Level Requirements ## - -The ASF requires that all artifacts in a release are cryptographically signed and distributed with hashes. - -OpenPGP is an asymmetric encryption scheme which lends itself well to the globally distributed nature of Apache. -Verification of a release artifact can be done using the signature and the release-maker's public key. Hashes -can be verified using the appropriate command (e.g. `sha1sum`, `md5sum`). - -An Apache release must contain a source-only artifact. This is the official release artifact. While a release of -an Apache project can contain other artifacts that do contain binary files. These non-source artifacts are for -user convenience only, but still must adhere to the same licensing rules. - -PMC members should take steps to verify that the source-only artifact does not contain any binary files. There is -some leeway in this rule. For example, test-only binary artifacts (such as test files or jars) are acceptable as long -as they are only used for testing the software and not running it. - -The following are the aforementioned Foundation-level documents provided for reference: - -* [Applying the Apache Software License][2] -* [Legal's license application guidelines][3] -* [Common legal-discuss mailing list questions/resolutions][4] -* [ASF Legal Affairs Page][5] - -## Apache Software License Application ## - -Application of the Apache Software License v2 consists of the following steps on each artifact in a release. It's -important to remember that for artifacts that contain other artifacts (e.g. a tarball that contains JAR files or -an RPM which contains JAR files), both the tarball, RPM and JAR files are subject to the following roles. - -The difficulty in verifying each artifact is that, often times, each artifact requires a different LICENSE and NOTICE -file. For example, the Accumulo binary tarball must contain appropriate LICENSE and NOTICE files considering the bundled -jar files in `lib/`. The Accumulo source tarball would not contain these same contents in the LICENSE and NOTICE files -as it does not contain those same JARs. - -### LICENSE file ### - -The LICENSE file should be present at the top-level of the artifact. This file should be explicitly named `LICENSE`, -however `LICENSE.txt` is acceptable but not preferred. This file contains the text of the Apache Software License -at the top of the file. At the bottom of the file, all other open source licenses _contained in the given -artifact_ must be listed at the bottom of the LICENSE file. Contained components that are licensed with the ASL themselves -do not need to be included in this file. It is common to see inclusions in file such as the MIT License of 3-clause -BSD License. - -### NOTICE file ### - -The NOTICE file should be present at the top-level of the artifact beside the LICENSE file. This file should be explicitly -name `NOTICE`, while `NOTICE.txt` is also acceptable but not preferred. This file contains the copyright notice for -the artifact being released. As a reminder, the copyright is held by the Apache Software Foundation, not the individual -project. - -The second purpose this file serves is to distribute third-party notices from dependent software. Specifically, other code -which is licensed with the ASLv2 may also contain a NOTICE file. If such an artifact which contains a NOTICE file is -contained in artifact being verified for releases, the contents of the contained artifact's NOTICE file should be appended -to this artifact's NOTICE file. For example, Accumulo bundles the Apache Thrift libthrift JAR file which also have its -own NOTICE file. The contents of the Apache Thrift NOTICE file should be included within Accumulo's NOTICE file. - -[1]: {{ site.baseurl }}/governance/releasing#testing -[2]: https://www.apache.org/dev/apply-license -[3]: https://www.apache.org/legal/src-headers -[4]: https://www.apache.org/legal/resolved -[5]: https://www.apache.org/legal http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71ede83/versioning.md ---------------------------------------------------------------------- diff --git a/versioning.md b/versioning.md deleted file mode 100644 index 654cec3..0000000 --- a/versioning.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Versioning ---- - -The Apache Accumulo PMC closed a vote on 2014/12/12 which adopted [Semantic Versioning 2.0.0][1] 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][2]. A copy of the specification is included here, licensed under -[Creative Commons - CC BY 3.0][3]: - -## Specification - -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. - -1. 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. - -2. 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. - -3. 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. - -4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be -considered stable. - -5. 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. - -6. 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. - -7. 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. - -8. 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. - -9. 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. - -10. 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. - -11. 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. - - -[1]: http://semver.org/spec/v2.0.0 -[2]: https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README.md;hb=refs/heads/master -[3]: https://creativecommons.org/licenses/by/3.0
