+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
