impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: [VOTE] Apache Impala Bylaws
Date Sat, 23 Jul 2016 02:08:02 GMT
+1 (not sure if mentors are considered part of PPMC, so not sure if mine's
binding or not)

On Fri, Jul 22, 2016 at 3:59 PM, Matthew Jacobs <mj@cloudera.com> wrote:

> +1 (binding)
>
> On Fri, Jul 22, 2016 at 3:46 PM, Harrison Sheinblatt
> <hsheinblatt@cloudera.com> wrote:
> > +1 (non-binding)
> >
> > On Fri, Jul 22, 2016 at 2:06 PM, Michael Brown <mikeb@cloudera.com>
> wrote:
> >
> >> +1 (non-binding)
> >>
> >> On Fri, Jul 22, 2016 at 12:46 PM, Jim Apple <jbapple@cloudera.com>
> wrote:
> >> > This is a vote on the following proposal for bylaws:
> >> >
> >> > https://gerrit.cloudera.org/#/c/3669/2
> >> >
> >> > The vote is to be done by "Lazy Consensus". Active PMC members,
> >> > according to http://incubator.apache.org/projects/impala.html, may
> >> > vote. The vote will be open 72 hours and will pass if there are "3
> >> > binding +1 votes and more binding +1 votes than -1 votes."
> >> >
> >> > +++++
> >> >
> >> > I am not on the PPMC, so my vote is non-binding. Here it is anyway, as
> >> > according to our draft bylaws, "Non binding votes are still useful for
> >> > those with binding votes to understand the perception of an action in
> >> > the wider Impala community."
> >> >
> >> > (Non-binding) +1.
> >> >
> >> > My reasoning is that these bylaws are probably not utterly bonkers,
> >> > since they are mostly what Hadoop uses, and they are easy to change if
> >> > anyone finds something problematic. Additionally, since many of us in
> >> > the Impala community are new to The Apache Way, having a document that
> >> > spells things out (like how voting works) will, I hope, serve as a
> >> > helpful foundation.
> >> >
> >> > +++
> >> >
> >> > Here is a plain-text copy of the patch for mailing-list archival
> >> purposes:
> >> >
> >> > +++
> >> >
> >> > Apache Impala (incubating) Project Bylaws
> >> >
> >> > Introduction
> >> >
> >> > This document defines the bylaws under which the Apache Impala
> >> > (incubating) project operates. It defines the roles and
> >> > responsibilities of the project, who may vote, how voting works, how
> >> > conflicts are resolved, etc.
> >> >
> >> > Impala is a project of the Apache Software Foundation. The foundation
> >> > holds the trademark on the name "Impala" and copyright on Apache code
> >> > including the code in the Impala codebase. The foundation FAQ explains
> >> > the operation and background of the foundation.
> >> >
> >> > Impala 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.
> >> >
> >> > 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.
> >> >
> >> > Users contribute to the Apache projects by providing feedback to
> >> > developers 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 Impala Project. 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 version
> >> > control repositories. Committers may cast binding votes on any
> >> > technical discussion.
> >> >
> >> > Committer access is by invitation only and must be approved by
> >> > consensus approval of the active PMC members. A Committer is
> >> > considered emeritus by their own declaration or by not contributing in
> >> > any form to the project for over six months. An emeritus committer may
> >> > request reinstatement of commit access from the PMC. Such
> >> > reinstatement is subject to consensus approval of active PMC members.
> >> >
> >> > Significant, pervasive features may be developed in a speculative
> >> > branch of the repository. The PMC may grant commit rights on the
> >> > branch to its consistent contributors for the duration of the
> >> > initiative. Branch committers are responsible for shepherding their
> >> > feature into an active release and do not cast binding votes or vetoes
> >> > in the project.
> >> >
> >> > All Apache committers are required to have a signed Contributor
> >> > License Agreement (CLA) on file with the Apache Software Foundation.
> >> > There is a Committer FAQ which provides more details on the
> >> > requirements for Committers
> >> >
> >> > A committer who makes a sustained contribution to the project may be
> >> > invited to become a member of the PMC. The form of contribution is not
> >> > limited to code. It can also include code review, helping out users on
> >> > the mailing lists, documentation, testing, etc.
> >> >
> >> > Release Manager
> >> > A Release Manager (RM) is a committer who volunteers to produce a
> >> > Release Candidate according to HowToRelease. The RM shall publish a
> >> > Release Plan on the dev@ list stating the branch from which they
> >> > intend to make a Release Candidate, at least one week before they do
> >> > so. The RM is responsible for building consensus around the content of
> >> > the Release Candidate, in order to achieve a successful Product
> >> > Release vote.
> >> >
> >> > Project Management Committee
> >> > The Project Management Committee (PMC) is responsible to the board and
> >> > the ASF for the management and oversight of the Apache Impala
> >> > codebase. The responsibilities of the PMC include
> >> >
> >> > Deciding what is distributed as products of the Apache Impala project.
> >> > In particular all releases must be approved by the PMC
> >> > Maintaining the project's shared resources, including the codebase
> >> > repository, mailing lists, and websites.
> >> > Speaking on behalf of the project.
> >> > Resolving license disputes regarding products of the project
> >> > Nominating new PMC members and committers
> >> > Maintaining these bylaws and other guidelines of the project
> >> > Membership of the PMC is by invitation only and must be approved by a
> >> > consensus approval of active PMC members. A PMC member is considered
> >> > "emeritus" by their own declaration or by not contributing in any form
> >> > to the project for over six months. An emeritus member may request
> >> > reinstatement to the PMC. Such reinstatement is subject to consensus
> >> > approval of the active PMC members.
> >> >
> >> > 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 Impala) and has primary responsibility to the board for the
> >> > management of the projects within the scope of the Impala PMC. The
> >> > chair reports to the board quarterly on developments within the Impala
> >> > project.
> >> >
> >> > The chair of the PMC is rotated annually. When the chair is rotated or
> >> > if the current chair of the PMC resigns, the PMC votes to recommend a
> >> > new chair using Single Transferable Vote (STV) voting. See BoardVoting
> >> > for specifics. The decision must be ratified by the Apache board.
> >> >
> >> > Decision Making
> >> >
> >> > Within the Impala project, different types of decisions require
> >> > different forms of approval. For example, the previous section
> >> > describes several decisions which require "consensus approval"
> >> > 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@impala.incubator.apache.org).
> >> > Where necessary, PMC voting may take place on the private Impala PMC
> >> > mailing list. Votes are clearly indicated by subject line starting
> >> > with [VOTE]. Votes may contain multiple items for approval and these
> >> > should be clearly separated. Voting is carried out by replying to the
> >> > vote mail. Voting may take four flavors
> >> >
> >> > +1 "Yes," "Agree," or "the action should be performed." In general,
> >> > this vote also indicates a willingness on the behalf of the voter in
> >> > "making 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 This is a negative vote. 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.
> >> > Patches are reviewed in the code review tool, where the vote flavors
> are:
> >> >
> >> > +2 "I am confident in the change and this can be committed without
> >> > further review after addressing the remaining points I have made."
> >> > +1 "I am OK with this being committed after the remaining points in my
> >> > comment have been addressed and someone else votes +2."
> >> > -1 "I oppose this being committed."
> >> > All participants in the Impala project are encouraged to show their
> >> > agreement with or against a particular action by voting. 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 in the wider Impala community.
> >> > For PMC decisions, only the votes of PMC members are binding.
> >> >
> >> > Approvals
> >> > These are the types of approvals that can be sought. Different actions
> >> > require different types of approvals
> >> >
> >> > Consensus Approval - Consensus approval requires 3 binding +1 votes
> >> > and no binding vetoes.
> >> > Lazy Consensus - Lazy consensus requires no -1 votes ('silence gives
> >> assent').
> >> > Lazy Majority - A lazy majority vote requires 3 binding +1 votes and
> >> > more binding +1 votes than -1 votes.
> >> > Lazy 2/3 Majority - Lazy 2/3 majority votes requires at least 3 votes
> >> > and twice as many +1 votes as -1 votes.
> >> > Vetoes
> >> > A valid, binding veto cannot be overruled. If a veto is cast, it must
> >> > be accompanied by a valid reason explaining the reasons for 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 - 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, any
> >> > 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.
> >> >
> >> > Code Change
> >> > A change made to a codebase of the project and committed by a
> >> > committer. This includes source code, documentation, website content,
> >> > etc.
> >> >
> >> > At least one +2 from a committer and no -1 from any committer.
> >> >
> >> > Product Release
> >> > When a release of one of the project's products is ready, a vote is
> >> > required to accept the release as an official release of the project.
> >> >
> >> > Lazy Majority of active PMC members
> >> >
> >> > New Branch Committer
> >> > When a branch committer is proposed for the PMC
> >> >
> >> > Lazy consensus of active PMC members
> >> >
> >> > New Committer
> >> > When a new committer is proposed for the project
> >> >
> >> > Consensus approval of active PMC members
> >> >
> >> > New PMC Member
> >> > When a committer is proposed for the PMC
> >> >
> >> > Consensus approval of active PMC members
> >> >
> >> > Branch Committer Removal
> >> > When removal of commit privileges is sought or when the branch is
> >> > merged to the mainline
> >> >
> >> > Lazy 2/3 majority of active PMC members
> >> >
> >> > Committer Removal
> >> > When removal of commit privileges is sought. Note: Such actions will
> >> > also be referred to the ASF board by the PMC chair
> >> >
> >> > Lazy 2/3 majority of active PMC members (excluding the committer in
> >> > question if a member of the PMC).
> >> >
> >> > PMC Member Removal
> >> > When removal of a PMC member is sought. Note: Such actions will also
> >> > be referred to the ASF board by the PMC chair.
> >> >
> >> > Lazy 2/3 majority of active PMC members (excluding the member in
> >> question)
> >> >
> >> > Modifying Bylaws
> >> > Modifying this document.
> >> >
> >> > Lazy majority of active PMC members
> >> >
> >> > Voting Timeframes
> >> > Votes are open for a period of 72 hours to allow all active voters
> >> > time to consider the vote. Votes relating to code changes are not
> >> > subject to a strict timetable but should be made as timely as
> >> > possible.
> >>
>



-- 
Todd Lipcon
Software Engineer, Cloudera

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message