Great hear. I will update the pull request accordingly. -Taylor
> On Feb 12, 2015, at 5:24 PM, Derek Dagit <[email protected]> wrote: > > I am OK with codifying the retroactive -1 as proposed by Nathan, and I > am otherwise OK with the proposed bylaws. > -- > Derek > > > > ----- Original Message ----- > From: Bobby Evans <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Sent: Thursday, February 12, 2015 8:12 AM > Subject: Re: [DISCUSS] Adopt Apache Storm Bylaws > > That seems fine to me. Most other projects I have worked on follow a similar > procedure, and a retroactive -1 can be applied, without having it codified, > but making it official seems fine to me. > I am +1 for those changes. > - Bobby > > > > On Thursday, February 12, 2015 2:23 AM, Nathan Marz > <[email protected]> wrote: > > > Yes, I would like to codify it. It's not about there being a bug with a > patch – it's about realizing that particular patch does not fit in with a > coherent vision of Storm, or that functionality could be achieved in a > completely different way. So basically, preventing bloat. With that change > I'm +1 to the bylaws and I believe we would have a consensus. > >> On Wed, Feb 11, 2015 at 7:34 PM, P. Taylor Goetz <[email protected]> wrote: >> >> I have no problem with your proposal. Actually I never even considered >> setting a timeline for a revert. I've always felt that if there was any >> problem with a patch/modification, it could be reverted at any time -- no >> deadline. If we find a problem, we fix it. We've reverted changes in the >> past, and lived to tell about it :). >> >> So I would think we don't even have to mention any revert timeline. If we >> feel the need to codify that, I'm okay with it. >> >> -Taylor >> >>> On Feb 11, 2015, at 9:06 PM, Nathan Marz <[email protected]> wrote: >>> >>> I'm -1 on these bylaws. This commit process encourages merging as fast as >>> possible and does not give adequate time for dissenting opinions to veto >> a >>> patch. I'm concerned about two things: >>> >>> 1. Regressions - Having too lax of a merge process will lead to >> unforeseen >>> regressions. We all saw this first hand with ZeroMQ: I had to freeze the >>> version of ZeroMQ used by Storm because subsequent versions would regress >>> in numerous ways. >>> 2. Bloat – All software projects have a tendency to become bloated and >>> build complexity because things were added piecemeal without a coherent >>> vision. >>> >>> These are very serious issues, and I've seen too many projects become >>> messes because of them. The only way to control these problems are with >>> -1's. Trust isn't even the issue here – one committer may very well >> think a >>> new feature "looks fine" and "why not let it in", while another will >>> recognize that the feature is unnecessary, adds complexity, and/or can be >>> addressed via better means. As is, the proposed bylaws are attempting to >>> make vetoing very difficult. >>> >>> I have a proposal which I believe gets the best of all worlds: allowing >> for >>> fast responsiveness on contributions while allowing for regressions and >>> bloat to be controlled. It is just a slight modification of the current >>> bylaws: >>> >>> "A minimum of one +1 from a Committer other than the one who authored the >>> patch, and no -1s. The code can be committed after the first +1. If a -1 >> is >>> received to the patch within 7 days after the patch was posted, it may be >>> reverted immediately if it was already merged." >>> >>> To be clear, if a patch was posted on the 7th and merged on the 10th, it >>> may be -1'd and reverted until the 14th. >>> >>> With this process patches can be merged just as fast as before, but it >> also >>> allows for committers with a more holistic or deeper understanding of a >>> part of Storm to prevent unnecessary complexity. >>> >>> >>> On Tue, Feb 10, 2015 at 7:48 AM, Bobby Evans <[email protected] >>> >>> wrote: >>> >>>> I am fine with this. I mostly want a starting point, and we can adjust >>>> things from there is need be. >>>> - Bobby >>>> >>>> >>>> On Sunday, February 8, 2015 8:39 PM, Harsha <[email protected]> >> wrote: >>>> >>>> >>>> >>>> Thanks for putting this together. Proposed bylaws looks good to >>>> me. -Harsha >>>> >>>> >>>>> On Thu, Feb 5, 2015, at 02:10 PM, P. Taylor Goetz wrote: >>>>> Associated pull request can be found here: >>>>> https://github.com/apache/storm/pull/419 >>>>> >>>>> >>>>> This is another attempt at gaining consensus regarding adopting >>>>> official bylaws for the Apache Storm project. The changes are minor >>>>> and should be apparent in the pull request diff. >>>>> >>>>> In earlier discussions, there were concerns raised about certain >>>>> actions requiring approval types that were too strict. In retrospect, >>>>> and after reviewing the bylaws of other project (Apache Drill [1], >>>>> Apache Hadoop [2]) as well as the official Glossary of Apache-Related >>>>> Terms [3], it seems that some of those concerns were somewhat >>>>> unfounded, and stemmed from the fact that different projects use >>>>> different and inconsistent names for various approval types. >>>>> >>>>> In an effort to remedy the situation, I have modified the “Approvals” >>>>> table to use the same names as the Glossary of Apache-Related Terms >>>>> [3]. The table below provides a mapping between the terms used in this >>>>> proposed update to the Apache Storm bylaws, the Apache Glossary, the >>>>> Apache Drill bylaws, and the Apache Hadoop bylaws. >>>>> >>>>> >>>>> | Proposed Storm Bylaws | Apache Glossary | Apache Drill | Apache >>>>> | Hadoop | Definition | >>>>> | >>>> >> -----------------------|--------------------|----------------|--------------------|-------------------------------------------------------------| >>>>> | Consensus Approval | Consensus Approval | Lazy Consensus | Consensus >>>>> | Approval | 3 binding +1 votes and no binding -1 votes | Majority >>>>> | Approval | Majority Approval | Lazy Majority | Lazy Majority | At >>>>> | least 3 binding +1 votes and more +1 votes than -1 votes | Lazy >>>>> | Consensus | Lazy Consensus | Lazy Approval | Lazy Consensus | No -1 >>>>> | votes (‘silence gives assent’) | >>>>> | 2/3 Majority | N/A | 2/3 Majority* | Lazy 2/3 Majority | At least 3 >>>>> | +1 votes and twice as many +1 votes as -1 votes | >>>>> >>>>> * The Apache Drill bylaws to not define “2/3 Majority” in the >>>>> Approvals table, but it is used in the Actions table. >>>>> >>>>> Please keep these differences in terminology when comparing the >>>>> proposed bylaws with those of other projects. >>>>> >>>>> I would like to use this DISCUSS thread as a forum for reaching >>>>> consensus to approve the proposed bylaws and to discuss any changes >>>>> needed to reach that point. If successful, the VOTE to officially >>>>> adopt the bylaws should be a technicality and pass without dissent. >>>>> >>>>> -Taylor >>>>> >>>>> >>>>> [1]https://cwiki.apache.org/confluence/display/DRILL/Project+Bylaws >>>>> [2]http://hadoop.apache.org/bylaws.html >>>>> [3]http://www.apache.org/foundation/glossary.html Email had 1 >>>>> attachment: >>>> >>>> >>>>> * signature.asc 1k (application/pgp-signature) >>> >>> >>> >>> -- >>> Twitter: @nathanmarz >>> http://nathanmarz.com >> > > > > -- > Twitter: @nathanmarz > http://nathanmarz.com >
