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
