I’m canceling this vote due to inactivity and so that we can discuss the concerns Ted raised.
Ted suggested we take a look at the Apache Drill bylaws. The main difference I see is the “Code Change” action: CODE CHANGE Storm: Approval: 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. Minimum Length: 2 days Drill: Approval: Consensus approval of active committers, with a minimum of one +1. The code can be committed after the first +1 Minimum Length: 1 day Beyond that, Drill uses much shorter durations for votes (usually 3 days, max of 6), and lazy consensus for more actions. Drill also has the same approval model for new committers/pmc members, while we list different approval for Committer/PMC. Since we propose new members for both Committter/PMC, we should probably use the same approval. In general, Drill uses shorter minimum vote lengths, and slightly more liberal approval requirements. I can see how Drill’s more relaxed approach would allow the project to move more quickly from a development perspective. The Drill bylaws can be found here: https://cwiki.apache.org/confluence/display/DRILL/Project+Bylaws The draft Storm bylaws can be found here: https://github.com/apache/storm/blob/fdbc5ebd081b6b8d6ed4da595ce6f0025343d0ee/BYLAWS.md I’d be in favor of relaxing our approval requirements, but I’d like to hear others’ opinions. Hopefully we can come up with a model we can all agree with. -Taylor On Nov 7, 2014, at 8:08 PM, Ted Dunning <[email protected]> wrote: > > 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
