Hi Nathan,
I am not clear on "7 days after the patch was posted" .
What happens if someone discover a bug after 7days past the
merge day.
IMO we do this method anyway we've seen 1 or 2 patches get in with an
issue and committers and contributors are happy to revert it and send in
a fix.
As Bobby suggested we can get the proposed bylaws as a starting point
and reevaluate those and adjust as necessary.
Not having these bylaws causing more confusion about the merge process.
Thanks,
Harsha
On Wed, Feb 11, 2015, at 06:06 PM, Nathan Marz 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
