Reply-To: dev@accumulo.apache.org Delivered-To: mailing list commits@accumulo.apache.org Received: (qmail 62320 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 24332E0772; Wed, 14 Dec 2016 14:34:09 +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:14 -0000 Message-Id: <395e3da67df94b87af0b0c59fa7a0019@git.apache.org> In-Reply-To: <26f702516ef6467d90fec2392e20f654@git.apache.org> References: <26f702516ef6467d90fec2392e20f654@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: [07/11] accumulo-website git commit: Jekyll build from master:a71056c archived-at: Wed, 14 Dec 2016 14:34:12 -0000 http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/contributor/voting.html ---------------------------------------------------------------------- diff --git a/contributor/voting.html b/contributor/voting.html new file mode 100644 index 0000000..2a7bc03 --- /dev/null +++ b/contributor/voting.html @@ -0,0 +1,251 @@ + + + + + + + + + + + + +Voting + + + + + + + + + + + + +

+ + +

+ +

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. 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
+See here for more mail templates

+ + +

+ + + + + +

+ + http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/docs-archive/index.html ---------------------------------------------------------------------- diff --git a/docs-archive/index.html b/docs-archive/index.html index dfdb043..bfba8db 100644 --- a/docs-archive/index.html +++ b/docs-archive/index.html @@ -97,8 +97,8 @@

Javadocs (1.8)

Examples (1.8)

Features

Papers & Presentations

@@ -108,9 +108,8 @@

http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/downloads/index.html ---------------------------------------------------------------------- diff --git a/downloads/index.html b/downloads/index.html index 6014000..4da7677 100644 --- a/downloads/index.html +++ b/downloads/index.html @@ -97,8 +97,8 @@

Javadocs (1.8)

Examples (1.8)

Features

Papers & Presentations

@@ -108,9 +108,8 @@

http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/example/wikisearch.html ---------------------------------------------------------------------- diff --git a/example/wikisearch.html b/example/wikisearch.html index 370f56d..09aa8e8 100644 --- a/example/wikisearch.html +++ b/example/wikisearch.html @@ -97,8 +97,8 @@

Javadocs (1.8)

Examples (1.8)

Features

Papers & Presentations

@@ -108,9 +108,8 @@

http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/external-docs/index.html ---------------------------------------------------------------------- diff --git a/external-docs/index.html b/external-docs/index.html new file mode 100644 index 0000000..8aabe74 --- /dev/null +++ b/external-docs/index.html @@ -0,0 +1,446 @@ + + + + + + + + + + + + +External Documentation + + + + + + + + + + + + +

+ + +

+ +

External Documentation

+ +

This page contains links to external documentation that may be useful to Accumulo users.

+ +

Papers and Presentations

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Title	Links	Category	Venue	Peer-Reviewed	Awards
Prout, Andrew, et al. “Enabling On-Demand Database Computing with MIT SuperCloud Database Management System.” IEEE HPEC 2015.	paper	Architecture	IEEE HPEC 2015	Yes
Hubbell, Matthew, et al. “Big Data Strategies for Data Center Infrastructure Management Using a 3D Gaming Platform.” IEEE HPEC 2015.	paper	Use Cases	IEEE HPEC 2015	Yes
Gadepally, Vijay, et al. “Computing on Masked Data to improve the Security of Big Data.” IEEE HST 2015.	paper	Use Cases	IEEE HST 2015	Yes
Kepner, Jeremy, et al. “Associative Arrays: Unified Mathematics for Spreadsheets, Databases, Matrices, and Graphs.” New England Database Summit 2015.	paper	Use Cases	New England Database Summit 2015	Yes
Achieving 100,000,000 database inserts per second using Accumulo and D4M - Kepner et al IEEE HPEC 2014	paper	Performance	IEEE HPEC 2014	Yes
Evaluating Accumulo Performance for a Scalable Cyber Data Processing Pipeline - Sawyer et al IEEE HPEC 2014	paper	Performance	IEEE HPEC 2014	Yes
Understanding Query Performance in Accumulo - Sawyer et al IEEE HPEC 2013	paper	Performance	IEEE HPEC 2013	Yes
Benchmarking Apache Accumulo BigData Distributed Table Store Using Its Continuous Test Suite - Sen et al 2013 IEEE International Congress on Big Data.	paper	Performance	IEEE International Congress on Big Data 2013	Yes
Benchmarking the Apache Accumulo Distributed Key-Value Store - Sen et al 2014 Updated version of the IEEE paper, including edits for clarity and additional results from benchmarking on Amazon EC2.	paper	Performance	Online	No
Computing on Masked Data: a High Performance Method for Improving Big Data Veracity - Kepner et al IEEE HPEC 2014	paper	Security	IEEE HPEC 2014	Yes
D4M 2.0 Schema: A General Purpose High Performance Schema for the Accumulo Database - Kepner et al IEEE HPEC 2013	paper slides	Architecture	IEEE HPEC 2013	Yes
Genetic Sequence Matching Using D4M Big Data Approaches - Dodson et al IEEE HPEC 2014		Use Cases	IEEE HPEC 2014	Yes	Best Paper Finalist
Big Data Dimensional Analysis - Gadepally et al IEEE HPEC 2014		Use Cases	IEEE HPEC 2014	Yes
LLSuperCloud: Sharing HPC systems for diverse rapid prototyping - Reuther et al IEEE HPEC 2013	paper slides	Architecture	IEEE HPEC 2013	Yes
Spatio-temporal indexing in non-relational distributed databases - Fox et al 2013 IEEE International Congress on Big Data	paper	Use Cases	IEEE International Congress on Big Data 2013	Yes
Typograph: Multiscale spatial exploration of text documents - Endert, Alex, et al 2013 IEEE International Congress on Big Data	paper	Use Cases	IEEE International Congress on Big Data 2013	Yes
UxV Data to the Cloud via Widgets - Charles et al 18th International Command & Control Research & Technology Symposium 2013	paper	Use Cases	Command & Control Research & Technology Symposium 2013	Yes
Driving Big Data With Big Compute - Byun et al IEEE HPEC 2012	paper slides	Architecture	IEEE HPEC 2012	Yes
Large Scale Network Situational Awareness Via 3D Gaming Technology - Hubbell et al IEEE HPEC 2012	paper slides	Use Cases	IEEE HPEC 2012	Yes
Rya: a scalable RDF triple store for the clouds - Punnoose et al 1st International Workshop on Cloud Intelligence, ACM, 2012	paper	Architecture	ACM International Workshop on Cloud Intelligence 2012	Yes
Dynamic distributed dimensional data model (D4M) database and computation system - Kepner et al ICASSP 2012	paper slides	Architecture	ICASSP 2012	Yes
An NSA Big Graph experiment (Technical Report NSA-RD-2013-056002v1)	slides	Performance	Technical Report	No
Patil, Swapnil, et al. “YCSB++: benchmarking and performance debugging advanced features in scalable table stores.” Proceedings of the 2nd ACM Symposium on Cloud Computing. ACM, 2011.	paper slides	Performance	ACM Symposium on Cloud Computing 2011	Yes
Turner, Keith “Apache Accumulo 1.4 & 1.5 Features.” February, 2012	slides	Architecture	Meetup	No
Fuchs, Adam “Accumulo: Extensions to Google’s Bigtable Design.” March, 2012	slides	Architecture	Meetup	No
Miner, Donald “An Introduction to Apache Accumulo - how it works, why it exists, and how it is used.” August, 2014	slides	Architecture	Online	No

+ + + +

Slides from Conferences and Meetups

+ +

Accumulo Summit Slides
Strata + Hadoop World Meetup 24 Oct 2012 +
+

+ +

Blog Posts and Writeups

+ +

Books

+ +

Reference

+ +

+ + +

+ + + + + +

+ + http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/features/index.html ---------------------------------------------------------------------- diff --git a/features/index.html b/features/index.html index 2857088..ca3a519 100644 --- a/features/index.html +++ b/features/index.html @@ -97,8 +97,8 @@

Javadocs (1.8)

Examples (1.8)

Features

Papers & Presentations

@@ -108,9 +108,8 @@

http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/feed.xml ---------------------------------------------------------------------- diff --git a/feed.xml b/feed.xml index 4287291..fa2e054 100644 --- a/feed.xml +++ b/feed.xml @@ -6,8 +6,8 @@ https://accumulo.apache.org/ - Tue, 06 Dec 2016 21:45:05 -0500 - Tue, 06 Dec 2016 21:45:05 -0500 + Wed, 14 Dec 2016 09:31:22 -0500 + Wed, 14 Dec 2016 09:31:22 -0500 Jekyll v3.3.0 http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/get_involved.html ---------------------------------------------------------------------- diff --git a/get_involved.html b/get_involved.html deleted file mode 100644 index a329ac2..0000000 --- a/get_involved.html +++ /dev/null @@ -1,244 +0,0 @@ - - - - - - - - - - - - -Get Involved - - - - - - - - - - - - -

- - -

- -

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”. 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. You can also look for Accumulo Meetups 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 for recommended practices in interacting with our source code. -Take a look at Accumulo’s Ohloh page for an analysis of the code base.

- -

Community Interaction

- -

Learn about building open source communities.

- -

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 is the first, and possibly the most important, consensus building -tool we have. Essentially lazy consensus means that you don’t need to get explicit -approval to proceed, but you need to be prepared to listen if someone objects.

- -

Consensus Building

- -

Sometimes lazy consensus is not appropriate. In such cases it is necessary to -make a proposal to the mailing list and discuss options. There are mechanisms -for quickly showing your support or otherwise for a proposal and -building consensus amongst the community.

- -

Once there is a consensus people can proceed with the work under the lazy -consensus model.

- -

Voting

- -

Occasionally a “feel” for consensus is not enough. Sometimes we need to -have a measurable consensus. For example, when voting in new committers or -to approve a release.

- - -

- - - - - -

- - http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/get_involved/index.html ---------------------------------------------------------------------- diff --git a/get_involved/index.html b/get_involved/index.html new file mode 100644 index 0000000..55ed08e --- /dev/null +++ b/get_involved/index.html @@ -0,0 +1,250 @@ + + + + + + + + + + + + +Get Involved + + + + + + + + + + + + +

+ + +

+ +

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.

+ +

Mailing lists and chat

+ +

Your first engagement with the project should be to subscribe to our +mailing lists. Apache Accumulo developers and community members +hang out in the #accumulo channel on irc.freenode.net.

+ +

Contributor Guide

+ +

See the contributor guide for recommended practices in interacting with our source code. +Take a look at Accumulo’s Ohloh page for an analysis of the code base.

+ +

Conferences and Meetups

+ +

Community Interaction

+ +

Learn about building open source communities.

+ +

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 is the first, and possibly the most important, consensus building +tool we have. Essentially lazy consensus means that you don’t need to get explicit +approval to proceed, but you need to be prepared to listen if someone objects.

+ +

Consensus Building

+ +

Sometimes lazy consensus is not appropriate. In such cases it is necessary to +make a proposal to the mailing list and discuss options. There are mechanisms +for quickly showing your support or otherwise for a proposal and +building consensus amongst the community.

+ +

Once there is a consensus people can proceed with the work under the lazy +consensus model.

+ +

Voting

+ +

Occasionally a “feel” for consensus is not enough. Sometimes we need to +have a measurable consensus. For example, when voting in new committers or +to approve a release.

+ + +

+ + + + + +

+ + http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/glossary/index.html ---------------------------------------------------------------------- diff --git a/glossary/index.html b/glossary/index.html index 598a9ae..ffc93dd 100644 --- a/glossary/index.html +++ b/glossary/index.html @@ -97,8 +97,8 @@

Javadocs (1.8)

Examples (1.8)

Features

Papers & Presentations

@@ -108,9 +108,8 @@

http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/fd45f7a2/governance/bylaws.html ---------------------------------------------------------------------- diff --git a/governance/bylaws.html b/governance/bylaws.html index d681cc4..801320d 100644 --- a/governance/bylaws.html +++ b/governance/bylaws.html @@ -1,438 +1,10 @@ - - - + - - - - - - - -Bylaws - - - - - - - - - - - - -

- - -

- -

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. The foundation holds the copyright on Apache code including the code in the Accumulo codebase. The 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 for more information on how Apache projects operate. Terms used at the ASF are defined in the ASF 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 (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 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. 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. -See the 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 defines the 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

- -

Release guidelines and details on the mechanics of creating an Accumulo release are available on the Accumulo project site.

- -

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - -

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 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.

- - - - - - - - - - - - - - - - - - - - - - -

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.

- -

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 policy. Assumed Lazy Approval has no minimum length of time before the change can be made.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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 and PMC members can only be removed with approval from the ASF Board.

- -

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.

- - -

- - - - - -

- +Redirecting… + + +

Redirecting…

+Click here if you are not redirected. +