Another issue is that releases should require a revote whenever the bits packaging the release change. The vote is as much on packaging as on the code.
Sent from my iPhone > On Nov 7, 2014, at 17:44, "P. Taylor Goetz" <[email protected]> wrote: > > Suresh brings up a good point with respect to feature branches (like the > security branch). > > We should have a provision for working in a feature branch within the Apache > repo with fewer restrictions. Without that, we are encouraging developers to > collaborate outside of Apache (I.e. p2p github pull requests, etc.). > > -Taylor > > > > >> On Nov 7, 2014, at 5:05 PM, Suresh Srinivas <[email protected]> wrote: >> >> Some comments inline: >>> On Fri, Nov 7, 2014 at 12:54 PM, P. Taylor Goetz <[email protected]> wrote: >>> >>> This is a call to vote on adopting the proposed bylaws (attached below) as >>> the bylaws for the Apache Storm project. >>> >>> For convenience, a rendered version of the markdown can be found here: >>> >>> >>> https://github.com/apache/storm/blob/fdbc5ebd081b6b8d6ed4da595ce6f0025343d0ee/BYLAWS.md >>> >>> This vote will be open for 7 days, and require a 2/3 majority of +1 votes >>> from PMC members. As always, all Storm community members are encouraged to >>> vote, though only PMC member votes will be considered binding. >>> >>> -Taylor >>> >>> >>> # Apache Storm Project Bylaws >>> >>> ## 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 developers start out as users and guide >>> their development efforts from the user's perspective. >>> >>> 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: >>> >>> Contributors are all of the volunteers who are contributing time, code, >>> documentation, or resources to the Storm 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 access to all project source repositories. >>> Committers may cast binding votes on any technical discussion regarding >>> storm. >>> >>> Committer access is by invitation only and must be approved by lazy >>> consensus 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 lazy consensus approval of active PMC members. >>> >>> All Apache Committers are required to have a signed Contributor License >>> Agreement (CLA) on file with the Apache Software Foundation. There is a >>> [Committers' FAQ](https://www.apache.org/dev/committers.html) 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. >>> >>> ### Project Management Committee(PMC): >>> >>> The PMC is responsible to the board and the ASF for the management and >>> oversight of the Apache Storm codebase. The responsibilities of the PMC >>> include: >>> >>> * Deciding what is distributed as products of the Apache Storm project. >>> In particular all releases must be approved by the PMC. >>> * Maintaining the project's shared resources, including the codebase >>> repository, mailing lists, 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 >>> Storm) and has primary responsibility to the board for the management of >>> the projects within the scope of the Storm PMC. The chair reports to the >>> board quarterly on developments within the Storm 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 >>> http://wiki.apache.org/general/BoardVoting for specifics. The decision >>> must be ratified by the Apache board. >>> >>> ## Voting >>> >>> Decisions regarding the project are made by votes on the primary project >>> development mailing list ([email protected]). Where >>> necessary, PMC voting may take place on the private Storm 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: >>> >>> | Vote | Meaning | >>> |------|---------| >>> | +1 | 'Yes,' 'Agree,' or 'the action should be performed.' | >>> | +0 | Neutral about the proposed action. | >>> | -0 | Mildly negative, but not enough so to want to block it. | >>> | -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. | >>> | >>> >>> All participants in the Storm 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 Storm community. For PMC decisions, >>> only the votes of active PMC members are binding. >>> >>> Voting can also be applied to changes already made to the Storm >>> codebase. These typically take the form of a veto (-1) in reply to the >>> commit message sent when the commit is made. Note that this should be a >>> rare occurrence. All efforts should be made to discuss issues when they >>> are still patches before the code is committed. >>> >>> Only active (i.e. non-emeritus) Committers and PMC members have binding >>> votes. >>> >>> ## Approvals >>> >>> These are the types of approvals that can be sought. Different actions >>> require different types of approvals >>> >>> | Approval Type | Criteria | >>> |---------------|----------| >>> | 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. >>> >>> | Actions | Description | Approval | Binding Votes | Minimum Length | >>> | Mailing List | >>> |---------|-------------|----------|---------------|----------------|--- >>> |-----------| >>> | Code Change | A change made to a source code of the project and >>> | committed by a Committer. | One +1 from a Committer other than the one >>> | who authored the patch, and no -1s. Code changes to a release require >>> | a re-vote on that release, but non-code changes do not require a >>> | re-vote. | Active Committers | 2 days from initial patch |JIRA or >>> | Github pull ( with notification sent to >> >> binding -1, right? >> >> In Apache Hadoop we do not have 2 days wait time. Why is that necessary >> given code can be reverted? Quick code may be required for high severity >> issues. Also do you want to consider feature branch merge differently? In >> case >> of hadoop three +1s are required for merging a feature branch. This >> helps in a set of contributors working freely on a separate branch and the >> code change can be reviewed before the merge. >> >> >>> | [email protected]) | >>> | Non-Code Change | A change made to a repository of the project and >>> | committed by a Committer. This includes documentation, website >>> | content, etc., but not source code, unless only comments are being >>> | modified. | Lazy Consensus | Active Committers | At the discression of >>> | the Committer |JIRA or Github pull (with notification sent to >>> | [email protected]) | >> >> Typo - discression >> >> >>> | Product Release | A vote is required to accept a proposed release as >>> | an official release of the project. Any Committer may call for a >>> | release vote at any point in time. | Lazy Majority | Active PMC >>> | members | 7 days | [email protected] | >>> | 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 and submodules within the >>> | project. | Lazy 2/3 majority | Active PMC members | 7 days | >>> | [email protected] | >>> | New Committer | When a new Committer is proposed for the project. | >>> | Lazy consensus | Active PMC members | 7 days | >>> | [email protected] | >>> | New PMC Member | When a Committer is proposed for the PMC. | Consensus >>> | Approval | Active PMC members | 7 days | >>> | [email protected] | >>> | Emeritus PMC Member re-instatement | When an emeritus PMC member >>> | requests to be re-instated as an active PMC member. | Consensus >>> | Approval | Active PMC members | 7 days | >>> | [email protected] | >>> | Emeritus Committer re-instatement | When an emeritus Committer >>> | requests to be re-instated as an active Committer. | Consensus >>> | Approval | Active PMC members | 7 days | >>> | [email protected] | >>> | Committer Removal | When removal of commit privileges is sought. Note: >>> | Such actions will also be referred to the ASF board by the PMC chair. >>> | | Consensus Approval | Active PMC members (excluding the Committer in >>> | question if a member of the PMC). | 7 Days | >>> | [email protected] | >>> | 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. >>> | | Consensus Approval | Active PMC members (excluding the member in >>> | question). | 7 Days | [email protected] | >>> | Modifying Bylaws | Modifying this document. | Lazy 2/3 majority | >>> | Active PMC members | 7 Days | [email protected] | >> >> >> >> -- >> http://hortonworks.com/download/ >> >> -- >> CONFIDENTIALITY NOTICE >> NOTICE: This message is intended for the use of the individual or entity to >> which it is addressed and may contain information that is confidential, >> privileged and exempt from disclosure under applicable law. If the reader >> of this message is not the intended recipient, you are hereby notified that >> any printing, copying, dissemination, distribution, disclosure or >> forwarding of this communication is strictly prohibited. If you have >> received this communication in error, please contact the sender immediately >> and delete it from your system. Thank You.
