+1 Andy Feng
Sent from my iPhone > On Feb 13, 2015, at 8:35 AM, Derek Dagit <der...@yahoo-inc.com.INVALID> wrote: > > +1 > > -- > Derek > > > > > ----- Original Message ----- > From: Bobby Evans <ev...@yahoo-inc.com.INVALID> > To: "dev@storm.apache.org" <dev@storm.apache.org> > Cc: > Sent: Friday, February 13, 2015 9:57 AM > Subject: Re: [DISCUSS] Adopt Apache Storm Bylaws > > +1 - Bobby > > > > On Friday, February 13, 2015 1:10 AM, Nathan Marz <nat...@nathanmarz.com> > wrote: > > > +1 > >> On Thu, Feb 12, 2015 at 5:57 PM, P. Taylor Goetz <ptgo...@gmail.com> 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 <ptgo...@gmail.com> wrote: >>> >>> Great hear. I will update the pull request accordingly. >>> >>> -Taylor >>> >>> >>>> On Feb 12, 2015, at 5:24 PM, Derek Dagit <der...@yahoo-inc.com.INVALID> >> 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 <ev...@yahoo-inc.com.INVALID> >>>> To: "dev@storm.apache.org" <dev@storm.apache.org> >>>> 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 < >> nat...@nathanmarz.com> 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 <ptgo...@gmail.com> >> 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 <nat...@nathanmarz.com> >> 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 >> <ev...@yahoo-inc.com.invalid >>>>>> >>>>>> 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 <st...@harsha.io> >>>>> 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
