Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id CC5BF200BDC for ; Wed, 14 Dec 2016 15:34:11 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id CAE4F160B13; Wed, 14 Dec 2016 14:34:11 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D503E160B2E for ; Wed, 14 Dec 2016 15:34:09 +0100 (CET) Received: (qmail 62022 invoked by uid 500); 14 Dec 2016 14:34:09 -0000 Mailing-List: contact commits-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list commits@accumulo.apache.org Received: (qmail 61934 invoked by uid 99); 14 Dec 2016 14:34:09 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Dec 2016 14:34:09 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id E17CCF169E; Wed, 14 Dec 2016 14:34:08 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: mwalch@apache.org To: commits@accumulo.apache.org Date: Wed, 14 Dec 2016 14:34:10 -0000 Message-Id: In-Reply-To: <26f702516ef6467d90fec2392e20f654@git.apache.org> References: <26f702516ef6467d90fec2392e20f654@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: [03/11] accumulo-website git commit: Several updates to website archived-at: Wed, 14 Dec 2016 14:34:12 -0000 Several updates to website * Combined governance and contributor guide pages * Added notes about testing/updating accumulo-examples during release * Consolidated release docs in two pages: making & verifying * Moved all pages at root of repo to pages/ (except index.md) but kept link structure * Renamed 'Papers & Presentation' to 'External Docs' as it contains links to books and blog posts. Project: http://git-wip-us.apache.org/repos/asf/accumulo-website/repo Commit: http://git-wip-us.apache.org/repos/asf/accumulo-website/commit/a71056ca Tree: http://git-wip-us.apache.org/repos/asf/accumulo-website/tree/a71056ca Diff: http://git-wip-us.apache.org/repos/asf/accumulo-website/diff/a71056ca Branch: refs/heads/master Commit: a71056ca8083b592325123cda70dd455bf687f32 Parents: b7e5e7b Author: Mike Walch Authored: Fri Dec 9 17:05:15 2016 -0500 Committer: Mike Walch Committed: Mon Dec 12 13:39:14 2016 -0500 ---------------------------------------------------------------------- _includes/nav.html | 5 +- contributor/bylaws.md | 195 +++++++++++++++++++++++++++++++++ contributor/consensusBuilding.md | 53 +++++++++ contributor/git.md | 8 +- contributor/index.md | 50 ++++++--- contributor/lazyConsensus.md | 58 ++++++++++ contributor/making-release.md | 165 ++++++++++++++++++++++++++++ contributor/rb.md | 4 +- contributor/releasing.md | 146 ------------------------ contributor/source.md | 5 - contributor/verifying-release.md | 130 ++++++++++++++++++++++ contributor/verifying_releases.md | 92 ---------------- contributor/voting.md | 93 ++++++++++++++++ get_involved.md | 93 ---------------- governance/bylaws.md | 193 -------------------------------- governance/consensusBuilding.md | 52 --------- governance/index.md | 9 -- governance/lazyConsensus.md | 57 ---------- governance/releasing.md | 51 --------- governance/voting.md | 92 ---------------- mailing_list.md | 49 --------- news.md | 19 ---- pages/external-docs.md | 110 +++++++++++++++++++ pages/get_involved.md | 99 +++++++++++++++++ pages/mailing_list.md | 50 +++++++++ pages/news.md | 20 ++++ pages/people.md | 182 ++++++++++++++++++++++++++++++ pages/related-projects.md | 92 ++++++++++++++++ pages/release.md | 6 +- papers.md | 6 - papers/index.md | 112 ------------------- people.md | 181 ------------------------------ projects.md | 90 --------------- 33 files changed, 1292 insertions(+), 1275 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/_includes/nav.html ---------------------------------------------------------------------- diff --git a/_includes/nav.html b/_includes/nav.html index c2a6eb2..d2f8531 100644 --- a/_includes/nav.html +++ b/_includes/nav.html @@ -28,8 +28,8 @@
  • Javadocs ({{ site.latest_minor_release }})
  • Examples ({{ site.latest_minor_release }})
  • Features
    • -
  • Papers & Presentations
  • Glossary
    • +
  • External Docs
  • Archive
    • @@ -39,9 +39,8 @@
  • Get Involved
  • Mailing Lists
  • People
    • -
  • Related Projects
    • +
  • Related Projects
  • Contributor Guide
    • -
  • Governance
    • http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/bylaws.md ---------------------------------------------------------------------- diff --git a/contributor/bylaws.md b/contributor/bylaws.md new file mode 100644 index 0000000..2d9da9b --- /dev/null +++ b/contributor/bylaws.md @@ -0,0 +1,195 @@ +--- +title: Bylaws +redirect_from: + - /bylaws + - /governance/bylaws +--- + +This is version 3 of the bylaws. Community work actively continues on the bylaws, and so key segments of them are subject to change. + +# Introduction + +This document defines the bylaws under which the Apache Accumulo project operates. It defines the roles and responsibilities of the project, who may vote, how voting works, how conflicts are resolved, etc. + +Accumulo is a project of the [Apache Software Foundation][foundation]. The foundation holds the copyright on Apache code including the code in the Accumulo codebase. The [foundation FAQ][foundation-faq] explains the operation and background of the foundation. + +Accumulo is typical of Apache projects in that it operates under a set of principles, known collectively as the Apache Way. If you are new to Apache development, please refer to the [Incubator project][incubator] for more information on how Apache projects operate. Terms used at the ASF are defined in the [ASF glossary][glossary]. + +# Roles and Responsibilities + +Apache projects define a set of roles with associated rights and responsibilities. These roles govern what tasks an individual may perform within the project. The roles are defined in the following sections. + +## Users + +The most important participants in the project are people who use our software. The majority of our contributors start out as users and guide their development efforts from the user's perspective. + +Users contribute to the Apache projects by providing feedback to contributors in the form of bug reports and feature suggestions. As well, users participate in the Apache community by helping other users on mailing lists and user support forums. + +## Contributors + +All of the volunteers who are contributing time, code, documentation, or resources to the Accumulo project are considered contributors. A contributor that makes sustained, welcome contributions to the project may be invited to become a committer, though the exact timing of such invitations depends on many factors. + +## Committers + +The project's committers are responsible for the project's technical management. Committers have write access to the project's code repositories and may cast binding votes on any technical discussion regarding Accumulo. Committer access is by invitation only and must be approved by consensus approval of the active PMC members. Upon acceptance of the invitation to become a committer, it is the accepting member’s responsibility to update their status on the Accumulo web page accordingly. + +A committer is considered emeritus, meaning inactive, by their own declaration or by not reviewing patches or committing patches to the project for over six months. Emeritus members will be recognized by the PMC on the Accumulo web page, in honor of their past contributions. Emeritus members retain all voting and commit rights associated with their former designation and can move themselves out of emeritus status by sending an announcement of their return to the developer mailing list. It will be the returning member's responsibility to update their status on the web page accordingly. + +An emeritus committer’s commit access may be disabled as part of routine security. Access shall not be removed without notifying the committer, and access shall be maintained if the committer wishes to leave it active. A committer’s commit access shall be reactivated upon the committer’s request to the PMC. + +All Apache committers are required to have a signed [Contributor License Agreement][icla] (CLA) on file with the Apache Software Foundation. Under the terms of the CLA that all committers must sign, a committer's primary responsibility is to ensure that all code committed to Apache Accumulo is licensed appropriately and meets those criteria set forth in the CLA (including both original works and patches committed on behalf of other contributors). There is a [Committer FAQ][committer-faq] which provides more details on the requirements for committers. + +It is the custom of the Accumulo project to also invite each committer to become a member of the Accumulo PMC. + +## Project Management Committee + +The role of the PMC, from a Foundation perspective, is [oversight][pmc-howto]. The main +role of the PMC is not code and not coding, but to ensure that all legal +issues are addressed, that procedure is followed, and that each and every +release is the product of the community as a whole. That is key to our +litigation protection mechanisms. + +Secondly, the role of the PMC is to further the long-term development and +health of the community as a whole, and to ensure that balanced and wide +scale peer review and collaboration does happen. Within the ASF, we worry +about any community which centers around a few individuals who are working +virtually uncontested. We believe that this is detrimental to quality, +stability, and robustness of both code and long term social structures. + +The responsibilities of the PMC include: + +* Deciding what is distributed as products of the Apache Accumulo project. +* Maintaining the project's shared resources, including the code repository, mailing lists, and websites. +* Protecting and ensuring proper use of Apache trademarks by the project and by other parties. +* Speaking on behalf of the project. +* Nominating new PMC members and committers. +* Maintaining these bylaws and other guidelines of the project. + +In particular, PMC members must understand both our project's criteria and ASF criteria for voting on a [release][release-management]. +See the [PMC Guide][pmc-guide] for more information on PMC responsibilities. + +Membership of the PMC is by invitation only and must be approved by a consensus approval of active PMC members. Upon acceptance of the invitation to become a PMC member, it is the accepting member’s responsibility to update their status on the Accumulo web page accordingly. + +A PMC member is considered emeritus, meaning inactive, by their own declaration or by not contributing in any form to the project for over six months. Emeritus members will be recognized by the PMC on the Accumulo web page, in honor of their past contributions. Emeritus members retain all voting and commit rights associated with their former designation and can move themselves out of emeritus status by sending an announcement of their return to the developer mailing list. It will be the returning member's responsibility to update their status on the web page accordingly. + +The chair of the PMC is appointed by the ASF board. The chair is an office holder of the Apache Software Foundation (Vice President, Apache Accumulo) and has primary responsibility to the board for the management of the projects within the scope of the Accumulo PMC. The chair reports to the board quarterly on developments within the Accumulo project. + +When the current chair of the PMC resigns, the PMC votes to recommend a new chair using consensus approval, but the decision must be ratified by the Apache board. + +## Release Manager + +The [ASF release process][release-pub] defines the [release manager][release-manager] as an individual responsible for shepherding a new project release. Any committer may serve as a release manager. The release manager for a release is chosen as part of the release plan. + +At a minimum, a release manager is responsible for packaging a release candidate for a vote and signing and publishing an approved release candidate. An Accumulo release manager is also expected to: + +* guide whether changes after feature freeze or code freeze should be included in the release +* ensure that required release testing is being conducted +* track whether the release is on target for its expected release date +* adjust release plan dates to reflect the latest estimates +* determine if a re-plan may be needed and, if so, call a vote +* call votes on release candidates + +Details on [making][making] and [verifying][verifying] a release are available on the Accumulo website. + +# Decision Making + +Within the Accumulo project, different types of decisions require different forms of approval. For example, the previous section describes several decisions which require 'consensus approval'. This section defines how voting is performed, the types of approvals, and which types of decision require which type of approval. + +## Voting + +Decisions regarding the project are made by votes on the primary project development mailing list: dev@accumulo.apache.org. Where necessary, PMC voting may take place on the private Accumulo PMC mailing list: private@accumulo.apache.org. Votes are clearly indicated by a subject line starting with [VOTE]. A vote message may only pertain to a single item’s approval; multiple items should be separated into multiple messages. Voting is carried out by replying to the vote mail. A vote may take on one of four forms, defined below. + +{: .table } +| Vote | Meaning | +|------|---------| +| +1 | *Yes*, *Agree*, or *The action should be performed*. In general, this vote also indicates a willingness on the behalf of the voter to *make it happen*. | +| +0 | This vote indicates a willingness for the action under consideration to go ahead. The voter, however, will not be able to help. | +| -0 | This vote indicates that the voter does not, in general, agree with the proposed action but is not concerned enough to prevent the action going ahead. | +| -1 | *No*, *Disagree*, or *The action should not be performed*. On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action. | + +All participants in the Accumulo project are encouraged to vote. For technical decisions, only the votes of active committers are binding. Non-binding votes are still useful for those with binding votes to understand the perception of an action across the wider Accumulo community. For PMC decisions, only the votes of active PMC members are binding. + +See the [voting page][voting] for more details on the mechanics of voting. + +## Commit Then Review (CTR) + +Voting can also be applied to changes to the Accumulo codebase. Under the Commit Then Review policy, committers can make changes to the codebase without seeking approval beforehand, and the changes are assumed to be approved unless an objection is raised. Only if an objection is raised must a vote take place on the code change. + +For some code changes, committers may wish to get feedback from the community before making the change. It is acceptable for a committer to seek approval before making a change if they so desire. + +## Approvals + +These are the types of approvals that can be sought. Different actions require different types of approvals. + +{: .table } +| Approval Type | Definition | +|-----------------------------------|--------------------------------------------------------------------------------------------------| +| Consensus Approval | A consensus approval vote passes with 3 binding +1 votes and no binding vetoes. | +| Majority Approval | A majority approval vote passes with 3 binding +1 votes and more binding +1 votes than -1 votes. | +| Lazy Approval (or Lazy Consensus) | An action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained. Lazy Approval can be either *stated* or *assumed*, as detailed on the [lazy consensus page][lazy]. | + +## Vetoes + +A valid, binding veto cannot be overruled. If a veto is cast, it must be accompanied by a valid reason explaining the veto. The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto, but merely that the veto is valid. + +If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, the action that has been vetoed must be reversed in a timely manner. + +## Actions + +This section describes the various actions which are undertaken within the project, the corresponding approval required for that action and those who have binding votes over the action. It also specifies the minimum length of time that a vote must remain open, measured in days. In general, votes should not be called at times when it is known that interested members of the project will be unavailable. + +For Code Change actions, a committer may choose to employ assumed or stated Lazy Approval under the [CTR][ctr] policy. Assumed Lazy Approval has no minimum length of time before the change can be made. + +{: .table } +| Action | Description | Approval | Binding Votes | Min. Length (days) | +|---------------------------|-------------------------------------------------------------------------------------------------------------|-------------------------------------------------------|--------------------|--------------------| +| Code Change | A change made to a codebase of the project. This includes source code, documentation, website content, etc. | Lazy approval, moving to consensus approval upon veto | Active committers | 1 | +| Release Plan | Defines the timetable and actions for an upcoming release. The plan also nominates a Release Manager. | Lazy approval, moving to majority approval upon veto | Active committers | 3 | +| Release Plan Cancellation | Cancels an active release plan, due to a need to re-plan (e.g., discovery of a major issue). | Majority approval | Active committers | 3 | +| Product Release | Accepts or rejects a release candidate as an official release of the project. | Majority approval | Active PMC members | 3 | +| Adoption of New Codebase | When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code base will continue. This also covers the creation of new sub-projects within the project. | Consensus approval | Active PMC members | 7 | +| New Committer | When a new committer is proposed for the project. | Consensus approval | Active PMC members | 3 | +| New PMC Member | When a committer is proposed for the PMC. | Consensus approval | Active PMC members | 3 | +| New PMC Chair | When a new PMC chair is chosen to succeed an outgoing chair. | Consensus approval | Active PMC members | 3 | +| Modifying Bylaws | Modifying this document. | Consensus approval | Active PMC members | 7 | + +No other voting actions are defined; all other actions should presume Lazy Approval (defaulting to Consensus Approval upon veto). If an action is voted on multiple times, or if a different approval type is desired, these bylaws should be amended to include the action. + +For the purposes of the "Adoption of New Codebase" action, the Accumulo codebase is defined as the Accumulo site content, primary project code, and all contributed code ("contribs") as they exist in their respective repositories. Adoption of a new codebase generally refers to the creation of a new contrib repository, but could cover, for example, a rework of the project site, or merging a contrib project into the primary codebase. + +Voting actions for the removal of a committer or PMC member are intentionally not defined. According to ASF rules, [committer status never expires][committer-terms] and [PMC members can only be removed with approval from the ASF Board][pmc-removal]. + +# Release Plans + +The approval of a release plan begins the process of creating a new project release. The process ends when a release candidate is approved. + +An Accumulo release plan consists of at least the following: + +* a version number +* a feature freeze date +* a code freeze date +* a release date +* the choice of a release manager + +After feature freeze, new features should not be accepted for the release. After code freeze, only critical fixes should be accepted for the release. The release manager guides the decision on accepting changes. + +All dates in a plan are estimates, as unforeseen issues may require delays. The release manager may adjust dates as needed. In serious circumstances, the release manager may opt to call a re-plan vote. + +[foundation]: https://www.apache.org/foundation +[foundation-faq]: https://www.apache.org/foundation/faq +[incubator]: https://incubator.apache.org +[glossary]: https://www.apache.org/foundation/glossary +[icla]: https://www.apache.org/licenses/icla.txt +[committer-faq]: https://www.apache.org/dev/committers +[pmc-howto]: https://www.apache.org/foundation/how-it-works.html#pmc +[release-management]: https://www.apache.org/dev/release#management +[pmc-guide]: https://www.apache.org/dev/pmc +[release-pub]: https://www.apache.org/dev/release-publishing +[release-manager]: https://www.apache.org/dev/release-publishing#release_manager +[making]: {{ "/contributor/making-release" | relative_url }} +[verifying]: {{ "/contributor/verifying-release" | relative_url }} +[voting]: {{ "/contributor/voting" | relative_url }} +[ctr]: #commit-then-review-ctr +[committer-terms]: https://www.apache.org/dev/committers#committer-set-term +[pmc-removal]: https://www.apache.org/dev/pmc#pmc-removal +[lazy]: {{ "/contributor/lazyConsensus" | relative_url }} http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/consensusBuilding.md ---------------------------------------------------------------------- diff --git a/contributor/consensusBuilding.md b/contributor/consensusBuilding.md new file mode 100644 index 0000000..4211854 --- /dev/null +++ b/contributor/consensusBuilding.md @@ -0,0 +1,53 @@ +--- +title: Consensus Building +redirect_from: /governance/consensusBuilding +--- + +In some cases there is no obvious path to take, or you might be a new community, +or a new member of an existing community. In these cases people will often +need to build consensus by making proposals and eliciting responses. + +We want to avoid unnecessary discussion and the creation of significant +amounts of unnecessary mail that everyone in the community needs to read. +That is not to say that we want to avoid constructive discussion. This is +the lifeblood of a successful project. However, many ASF projects adopt a +shorthand notation for showing support, or otherwise, for a proposal. + +## Expressing support (or otherwise) + +The notation used is "+1", "-1" and "0". It's also common to see "+0" and "-0". + +So, what do these notations mean? + + - +1 means "I agree with this and will help make it happen" + - +0 means "I agree with this but probably won't make it happen, so my +opinion is not that important" + - -0 means "I don't agree with this, but I'm offering no alternative so +my opinion is not that important" + - -1 means "I don't agree and I am offering an alternative that I am able +to help implement" + +Many people will use fractions to indicate the strength of their feelings, + e.g. "+0.5". Some will even indicate this is a "no brainer" with something +like "+1000". + +The important thing is that this is not an exact science. It's just a shorthand +way of communicating strength of feeling. + +## Consensus Building is Not Voting + +The confusing thing about this notation is that it is the same notation +used in a formal vote. Knowing when something is a vote and when it is a +preference is important. It's easy to tell though, if the subject does not have +"[Vote]" at the start then it's just an opinion. We try not to call votes, +consensus building is much more inclusive. + +The reasons for this notation being common is +that when someone wants to summarise a discussion thread they can mentally +add up the strength of feeling of the community and decide if there is consensus +or not. + +Once there is a clear consensus members of the community can proceed with +the work under the [lazy consensus][1] model. + +[1]: {{ site.baseurl }}/contributor/lazyConsensus http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/git.md ---------------------------------------------------------------------- diff --git a/contributor/git.md b/contributor/git.md index 278ae1d..95128cf 100644 --- a/contributor/git.md +++ b/contributor/git.md @@ -349,9 +349,7 @@ 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: -1. Prepare the release candidate. [Release - Guide]({{ site.baseurl }}/governance/releasing), [Maven - Instructions]({{ site.baseurl }}/releasing) +1. [Make a release candidate][making] 2. Create a branch for the release candidate from the `x.y` branch, named something like `x.y.z'-RCN`. 3. Test and Vote @@ -371,7 +369,7 @@ the `z` value back to `0`. The steps to create a new major release are very similar to a minor release: -1. Prepare the release candidate. _reference release instructions_ +1. [Make a release candidate][making] 2. Create a tag of the release candidate from the `x.y` branch, named something like `x.y.0-RCN`. 3. Test and Vote @@ -450,4 +448,4 @@ For the sake of clarity, some examples of common situations are included below. [1]: https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow - +[making]: {{ site.baseurl }}/contributor/making-release http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/index.md ---------------------------------------------------------------------- diff --git a/contributor/index.md b/contributor/index.md index 3902a17..329f4a9 100644 --- a/contributor/index.md +++ b/contributor/index.md @@ -2,28 +2,48 @@ title: Contributor Guide --- -This page contains resources and documentation for Accumulo contributors. +This page contains resources and documentation for Accumulo contributors. Any documentation that is helpful +to Accumulo users should go in the [Accumulo User Manual][manual]. -Any documentation that is helpful to Accumulo users should be placed in the [user manual][manual]. +## External project resources -* [JIRA] - Accumulo's Issue Tracker -* [GitHub] - Pull requests can be made on GitHub -* [Jenkins] & [TravisCI] - Accumulo build servers -* [Source Guide]({{ "/contributor/source" | relative_url }}) -* [Git Workflow]({{ "/contributor/git" | relative_url }}) -* [Versioning]({{ "/contributor/versioning" | relative_url }}) -* [Contrib Projects]({{ "/contributor/contrib-projects" | relative_url }}) -* [Review Board]({{ "/contributor/rb" | relative_url }}) +* [JIRA] for tracking issues +* [GitHub] for code reviews (via pull requests) +* [Jenkins] & [TravisCI] for automated builds -Below are resources for Accumulo committers which may also be helpful to contributors. +## Development docs -* [Making Releases][making] -* [Verifying Releases][verifying] +* [Source Guide][source] +* [Git Workflow][git] +* [Versioning][versioning] +* [Contrib Projects][contrib-projects] +* [Review Board][rb] + +## Release guides + +* [Making a release][making] +* [Verifying a release][verifying] + +## Project governance + +* [Bylaws](/contributor/bylaws) +* [Consensus Building](/contributor/consensusBuilding) +* [Lazy Consensus](/contributor/lazyConsensus) +* [Voting](/contributor/voting) [manual]: {{ site.baseurl }}/{{ site.latest_minor_release }}/accumulo_user_manual.html [JIRA]: https://issues.apache.org/jira/browse/ACCUMULO [GitHub]: https://github.com/apache/accumulo/pulls [Jenkins]: https://builds.apache.org/view/A/view/Accumulo [TravisCI]: https://travis-ci.org/apache/accumulo -[making]: {{ "/contributor/releasing" | relative_url }} -[verifying]: {{ "/contributor/verifying_releases" | relative_url }} +[source]: {{ "/contributor/source" | relative_url }} +[git]: {{ "/contributor/git" | relative_url }} +[versioning]: {{ "/contributor/versioning" | relative_url }} +[contrib-projects]: {{ "/contributor/contrib-projects" | relative_url }} +[rb]: {{ "/contributor/rb" | relative_url }} +[making]: {{ "/contributor/making-release" | relative_url }} +[verifying]: {{ "/contributor/verifying-release" | relative_url }} +[bylaws]: {{ "/contributor/bylaws" | relative_url }} +[consensus-building]: {{ "/contributor/consensusBuilding" | relative_url }} +[lazyConsensus]: {{ "/contributor/lazyConsensus" | relative_url }} +[voting]: {{ "/contributor/voting" | relative_url }} http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/lazyConsensus.md ---------------------------------------------------------------------- diff --git a/contributor/lazyConsensus.md b/contributor/lazyConsensus.md new file mode 100644 index 0000000..367a0f1 --- /dev/null +++ b/contributor/lazyConsensus.md @@ -0,0 +1,58 @@ +--- +title: Lazy Consensus +redirect_from: /governance/lazyConsensus +--- + +The concept of "Lazy Consensus" is very important in our project. Lazy +Consensus means that when you are convinced that you know what the community +would like to see happen you can simply assume that you already have consensus +and get on with the work. You don't have to insist people discuss and/or +approve your plan, and you certainly don't need to call a vote to get approval. +You just assume you have the community's support unless someone says otherwise. + +We have a time machine (Subversion), this means that as long as you commit +(or submit patches) early and often the community has plenty of opportunity +to indicate disapproval. If you believe the community will support your action +you can operate on lazy consensus as long as you are prepared to roll back +any work should a valid objection is raised. + +## Avoiding Unnecessary Discussion + +The key thing about lazy consensus is that it's easier for people to agree, +by doing nothing, than it is to object, which requires an +alternative to be proposed. This has two effects, firstly people are less +likely to object for the sake of it and secondly it cuts down on the amount +of unnecessary mail traffic and discussion. + +Lazy consensus means we can avoid waiting for a community based decision +before proceeding. However, it does require everyone who cares for the health +of the project to watch what is happening, as it is happening. Objecting too +far down the road will cause upset, but objecting (or asking for clarification +of intent) early is likely to be greeted with relief that someone is watching +and cares. + +## Stating Lazy Consensus + +Sometimes a member of the community will believe a specific action is the correct +one for the community but are not sure enough to proceed with the work under the +lazy consensus model. In these circumstances they can state Lazy Consensus is in +operation. + +What this means is that they make a proposal and state that they will start +implementing it in 72 hours unless someone objects. 72 hours is chosen because +it accounts for different timezones and non-apache commitments. + +In this approach the original proposal is not insisting that there is a discussion +around their proposal, nor are they requesting that the community explicitly +supports their actions. However, this differs from assuming lazy consensus +since it allows space and time to [express support or objections][1] and corrections to +the proposal before work begins. + +## Silence is consent + +People may choose to indicate their support for the actions taken with a +1 +mail - quick and easy to read and reassuring for the implementer. However, +remember, in a lazy consensus world silence is the equivalent to support. This +can take some time to get used to. + +[1]: {{ site.baseurl }}/contributor/consensusBuilding http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/making-release.md ---------------------------------------------------------------------- diff --git a/contributor/making-release.md b/contributor/making-release.md new file mode 100644 index 0000000..41a3e85 --- /dev/null +++ b/contributor/making-release.md @@ -0,0 +1,165 @@ +--- +title: Making a Release +redirect_from: + - /releasing + - /contributor/releasing + - /governance/releasing +--- + +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:dev@accumulo.apache.org) and get the ball rolling. Developers should test and verify the +release candidate on their own. Accumulo has a guide for [verifying releases][verify]. + +Lazy consensus is not sufficient for a release; at least 3 +1 votes from PMC members are required. All +checksums and signatures need to be verified before any voter can +1 it. Voting shall last 72 hours. Voters +SHOULD include with their vote details on the tests from the testing section they have successfully run. +If given, said details for each test MUST include: the number of worker nodes in the cluster, the operating system +and version, the Hadoop version, and the Zookeeper version. For testing done on a version other than the release +candidate that is deemed relevant, include the commit hash. All such gathered testing information will be included +in the release notes. + +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, follow the steps below. + +## 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 a post in `_posts/release/` containing release notes (ensure notes contain link to JIRA changes for that version) + * Remove previous bug-fix release (if applicable) + * 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. In a different directory, checkout the `master` branch of the accumulo-website repo +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 in the website branch (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 `master` and `asf-site` branches back to the accumulo-website repo +11. Verify that javadocs have been updated on the production site (e.g. https://accumulo.apache.org/1.6/apidocs/) + +## Update Accumulo Examples + +After the release has been made, the Accumulo version used by [Accumulo Examples][examples] should be updated +if this is the latest release of Accumulo. + + * Update the `accumulo.version` property in `pom.xml` of accumulo-examples + * Run `mvn clean verify` to confirm that nothing breaks + * Run one of the examples for additinal testing. + +## References + +Some good references that explain a few things: + +- [Christopher talks about making releases][3] +- [Publishing Maven Artifacts][4] +- [Publishing Releases][5] + +[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 +[7]: https://www.kb.cert.org/vuls/id/225657 +[8]: https://www.apache.org/dev/cmsref#extpaths +[addrelease]: https://reporter.apache.org/addrelease?accumulo +[verify]: {{ "/contributor/verifying-release" | relative_url }} +[examples]: https://github.com/apache/accumulo-examples http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/rb.md ---------------------------------------------------------------------- diff --git a/contributor/rb.md b/contributor/rb.md index dccbb40..3630e09 100644 --- a/contributor/rb.md +++ b/contributor/rb.md @@ -102,7 +102,7 @@ They should be in the form of a patch containing a single commit, [rbinstance]: https://reviews.apache.org [rb]: https://www.reviewboard.org -[bylaws]: {{ "/governance/bylaws" | relative_url }} +[bylaws]: {{ "/contributor/bylaws" | relative_url }} [ctr]: https://www.apache.org/foundation/glossary#CommitThenReview -[actions]: {{ "/governance/bylaws#actions" | relative_url }} +[actions]: {{ "/contributor/bylaws#actions" | relative_url }} [contributor]: {{ "/contributor/git#contributors" | relative_url }} http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/releasing.md ---------------------------------------------------------------------- diff --git a/contributor/releasing.md b/contributor/releasing.md deleted file mode 100644 index 7488df8..0000000 --- a/contributor/releasing.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -title: Making a Release -redirect_from: /releasing ---- - -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:dev@accumulo.apache.org) 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. In a different directory, checkout the `master` branch of the accumulo-website repo -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 in the website branch (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 `master` and `asf-site` branches back to the accumulo-website repo -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/a71056ca/contributor/source.md ---------------------------------------------------------------------- diff --git a/contributor/source.md b/contributor/source.md index 4ae22ea..466f5e2 100644 --- a/contributor/source.md +++ b/contributor/source.md @@ -202,10 +202,6 @@ Accumulo has [guidelines for using Review Board][rb] to support code reviews. * 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 @@ -228,7 +224,6 @@ Accumulo's release guide can be found [here][release]. [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]: {{ "/contributor/rb" | relative_url }} -[release]: {{ "/governance/releasing" | relative_url }} [site-canon]: https://accumulo.apache.org [site-mirror]: http://apache.github.io/accumulo [srcheaders]: https://www.apache.org/legal/src-headers http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/verifying-release.md ---------------------------------------------------------------------- diff --git a/contributor/verifying-release.md b/contributor/verifying-release.md new file mode 100644 index 0000000..f9a2217 --- /dev/null +++ b/contributor/verifying-release.md @@ -0,0 +1,130 @@ +--- +title: Verifying a Release +redirect_from: /verifying_releases +--- + +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. + +## Versioning + +Accumulo has adopted [Semantic Versioning][versioning] and follows their rules and guidelines. + +## Testing basics + +Each release of Accumulo should be tested by the community to verify correctness. + +Below are some suggested tests that can be run (feel free to run your own custom tests too): + +* Run Accumulo's unit and integration tests using the following command: + + $ mvn verify + +* Build the [Accumulo Examples][examples] repo using the release candidate by updating the `accumulo.version` + property in the `pom.xml` and using the staging repo. Also, run the unit/integration tests using `mvn verify`. + +* Run Accumulo's distributed tests (i.e RandomWalk, ContinuousIngest, etc). 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. + +## Project testing goals + +While contributors do not need perform all tests, there should a minimum amount of testing done by the project as whole before a release is made. + +Testing for an Accumulo release includes a few steps that a developer may take without a Hadoop cluster and several that require a working cluster. For minor releases, +the tests which run on a Hadoop cluster are recommended to be completed but are not required. Running even a reduced set of tests against real hardware is always encouraged +even if the full test suite (in breadth of nodes or duration) is not executed. If PMC members do not believe adequate testing was performed for the sake of making the proposed +release, the release should be vetoed via the normal voting process. New major releases are expected to run a full test suite. + +### Stand alone + +The following steps can be taken without having an underlying cluster. They SHOULD be handled with each Hadoop profile available for a given release version. To activate an alternative profile specify e.g. "-Dhadoop.profile=2" for the Hadoop 2 profile on the Maven commandline. Some older versions of Accumulo referred to Hadoop profiles diferently; see the README that came with said versions for details on building against different Hadoop versions. + + 1. All JUnit tests must pass. This should be a requirement of any patch so it should never be an issue of the codebase. + - Use "mvn package" to run against the default profile of a particular release + - Use "mvn -Dhadoop.profile=2 package" to test against the Hadoop 2 profile on e.g. 1.4 or 1.5 + - Use "mvn -Dhadoop.profile=1 package" to test against the Hadoop 1 profile on e.g. 1.6 or later + - Analyze output of static analysis tools like Findbugs and PMD. + - For versions 1.6 and later, all functional tests must pass via the Maven failsafe plugin. + - Use "mvn verify" to run against the default profile of a particular release + - Use "mvn -Dhadoop.profile=1 verify" to run the functional tests against the Hadoop 1 profile + +### Cluster based + +The following tests require a Hadoop cluster running a minimum of HDFS, MapReduce, and ZooKeeper. The cluster MAY have any number of worker nodes; it can even be a single node in pseudo-distributed mode. A cluster with multiple tablet servers SHOULD be used so that more of the code base will be exercised. For the purposes of release testing, you should note the number of nodes and versions used. See the Releasing section for more details. + + 1. For versions prior to 1.6, all functional tests must complete successfully. + - See $ACCUMULO_HOME/test/system/auto/README for details on running the functional tests. + - Two 24-hour periods of the LongClean module of the RandomWalk test need to be run successfully. One of them must use agitation and the other should not. + - See $ACCUMULO_HOME/test/system/randomwalk/README for details on running the LongClean module. + - Two 24-hour periods of the continuous ingest test must be validated successfully. One test period must use agitation and the other should not. + - See $ACCUMULO_HOME/test/system/continuous/README for details on running and verifying the continuous ingest test. + - Two 72-hour periods of continuous ingest must run. One test period must use agitation and the other should not. No validation is necessary but the cluster should be checked to ensure it is still functional. + +## 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. + +[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 +[examples]: https://github.com/apache/accumulo-examples +[versioning]: {{ site.baseurl }}/contributor/versioning http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/contributor/verifying_releases.md ---------------------------------------------------------------------- diff --git a/contributor/verifying_releases.md b/contributor/verifying_releases.md deleted file mode 100644 index f36ef49..0000000 --- a/contributor/verifying_releases.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Verifying a Release -redirect_from: /verifying_releases ---- - -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/a71056ca/contributor/voting.md ---------------------------------------------------------------------- diff --git a/contributor/voting.md b/contributor/voting.md new file mode 100644 index 0000000..4ee6437 --- /dev/null +++ b/contributor/voting.md @@ -0,0 +1,93 @@ +--- +title: Voting +redirect_from: /governance/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. + +## Preparing for a Vote + +Before calling a vote it is important to ensure that the community is given time to +discuss the upcoming vote. This will be done by posting an email to the list +indicating the intention to call a vote and the options available. By the time a +vote is called there should already be [consensus in the community][1]. The vote +itself is, normally, a formality. + +## Calling a Vote + +Once it is time to call the vote a mail is posted with a subject starting with +"[VOTE]". This enables the community members to ensure they do not miss an important +vote thread. It also indicates that this is not consensus building but a formal +vote. The initiator is responsible for the vote. That means also to count the votes +and present the results. Everyone has 1 vote. + +### Casting Your Vote + +The notation used in voting is: + ++1 (means I vote positive) + You can say why you vote positive but it's not a must-have. + + 0 (means I have no strong opinion, aka abstention) + +-1 (means I vote negative because of the following reason) + Yes, you must support your objection and provide an alternative course of action + that you are willing and able to implement (where appropriate). + +#### Example for a vote mail: + + Address: private@ + Subject: [VOTE] John Doe should become a regular committer + + Text: + "I would like to propose to vote in John Doe as committer. John has showed in + the last months that he has the skills and oversight for improving things (think + about the last UI change of the "Find" dialog)." + + +1 (means I vote for John) + 0 (means I'm not for John but also not against to vote him in) + -1 (means I'm not for John because of the following reason(s): + + Voting time frame is finished 72 hours from now until June 30, 12:00 PM UTC. + +#### Example for a reply mail: + + Text: + +1 + + I like his work and want him to stay and to go on with his good improvements. + + +#### Example for a result mail: + + Subject: [VOTE][RESULTS] John Doe should become a regular committer + + Text: + Vote started Thu, Jun 27, 2011 at 12:00 PM UTC, voting is now closed. + + Voting results: + + --- Numbers --- + + +1: 6 + 0: 0 + -1: 0 + + --- Details --- + + +1 John + +1 Jane + +1 David + +1 Dolores + +1 Carl + +1 Chris + +[See here for more information][2]
    +[See here for more mail templates][3] + + +[1]: consensusBuilding +[2]: https://www.apache.org/foundation/voting +[3]: https://community.apache.org/newcommitter http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/a71056ca/get_involved.md ---------------------------------------------------------------------- diff --git a/get_involved.md b/get_involved.md deleted file mode 100644 index 52d37a3..0000000 --- a/get_involved.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Get Involved ---- - -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 a 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"][1]. 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 Meetups - -Your first engagement with the project should be to subscribe to our -[mailing lists][2]. You can also [look for Accumulo Meetups][3] in your area. -Apache Accumulo developers and community members hang out in the #accumulo -channel on irc.freenode.net. - -## Contributor Guide - -See the [contributor guide][4] for recommended practices in interacting with our source code. -Take a look at [Accumulo's Ohloh page][5] for an analysis of the code base. - -## Community Interaction - -Learn about [building open source communities][6]. - -## Decision Making - -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][7] 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][8] amongst the community. - -Once there is a consensus people can proceed with the work under the [lazy -consensus][9] model. - -### Voting - -Occasionally a "feel" for consensus is not enough. Sometimes we need to -have a measurable consensus. For example, when [voting][10] in new committers or -to approve a release. - -[1]: https://s.apache.org/newbie_accumulo_tickets -[2]: {{ site.baseurl }}/mailing_list -[3]: https://www.meetup.com/find/?keywords=accumulo -[4]: {{ site.baseurl }}/contributor/ -[5]: https://www.ohloh.net/p/accumulo -[6]: http://www.betaversion.org/~stefano/papers/ac2006.2.pdf -[7]: {{ site.baseurl }}/governance/lazyConsensus -[8]: {{ site.baseurl }}/governance/consensusBuilding -[9]: {{ site.baseurl }}/governance/lazyConsensus -[10]: {{ site.baseurl }}/governance/voting