impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Apple <jbap...@cloudera.com>
Subject Re: [VOTE] Apache Impala Bylaws
Date Mon, 25 Jul 2016 21:36:15 GMT
Thanks to everyone who voted.

72 hours has elapsed; this vote has passed.

On Mon, Jul 25, 2016 at 2:29 PM, Ippokratis Pandis <ippokratis@gmail.com> wrote:
> +1 (non-binding)
>
> On Sat, Jul 23, 2016 at 10:04 PM, Bharath Vissapragada <
> bharathv@cloudera.com> wrote:
>
>> +1 (non-binding)
>>
>> On Sun, Jul 24, 2016 at 5:41 AM, Michael Ho <kwho@cloudera.com> wrote:
>>
>> > +1 (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.
>> > >
>> >
>> >
>> >
>> > --
>> > Thanks,
>> > Michael
>> >
>>
>>
>>
>> --
>> Thanks,
>> Bharath
>>
>
>
>
> --
> -Ippokratis.

Mime
View raw message