+1
On Fri, Feb 13, 2015, at 07:57 AM, Bobby Evans wrote: > +1 - Bobby > > > On Friday, February 13, 2015 1:10 AM, Nathan Marz > <[email protected]> wrote: > > > +1 > > On Thu, Feb 12, 2015 at 5:57 PM, P. Taylor Goetz <[email protected]> > wrote: > > > Pull request updated. > > > > Here’s a link to the latest commit: > > https://github.com/ptgoetz/storm/commit/18a68a074570db01fc6377a269feb90ecda898ab > > > > - Taylor > > > > On Feb 12, 2015, at 8:41 PM, P. Taylor Goetz <[email protected]> wrote: > > > > > 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 > > >> > > > > > > > -- > Twitter: @nathanmarz > http://nathanmarz.com > >
