I just put up https://github.com/apache/incubator-storm/pull/173 for this.
On 6/30/14, 11:43 AM, "Bobby Evans" <[email protected]> wrote: >How about I update the document to take into account Nathan¹s comments. >Then turn it into a formal pull request. Then we can continue the >discussion, and put more pull requests on top of it until we graduate and >have a formal vote on adoption. Then at that point we can move the bylaws >into the subversion web page repo, or add a link to the github repo for >the bylaws. Either way is fine with me. > >I am canceling the vote. > >- Bobby > >On 6/28/14, 3:15 PM, "P. Taylor Goetz" <[email protected]> wrote: > >>I agree completely! >> >>I think adding ³work in progress² or ³DRAFT² in the title will prevent >>any confusion. And maybe cancel the vote and treat it more like a patch >>for now. Then when it¹s time to formally adopt the bylaws, we can hold >>the official vote. >> >>- Taylor >> >>On Jun 28, 2014, at 2:31 PM, Nathan Marz <[email protected]> wrote: >> >>> My impression was that this was a vote to adopt the bylaws, since it >>>says >>> "proposed bylaws" and the vote required consensus approval. >>> >>> Regardless, I agree that we should merge it into source control and >>> collaborate on it with pull requests/comments, and we should delay a >>>vote >>> until everyone's issues have been addressed. However, let's add "work >>>in >>> progress" to the title so people don't get confused. >>> >>> >>> On Sat, Jun 28, 2014 at 7:30 AM, P. Taylor Goetz <[email protected]> >>>wrote: >>> >>>> I¹m +1. >>>> >>>> I think with Bobby¹s latest changes it makes it abundantly clear that >>>>it >>>> is a working draft, and we are not voting to adopt them. I see this as >>>>a >>>> vote to pull the draft into source control so individual changes can >>>>be >>>> proposed and discussed as opposed to trying to approve the document in >>>>it¹s >>>> entirety. >>>> >>>> Trying to get everything right all at once places undue burden on >>>>Bobby ‹ >>>> a veto forces him to cancel the vote, interpret the comments, reword >>>>things >>>> to address the comments, and initiate a new vote. Bobby was kind >>>>enough to >>>> put it together in the first place. >>>> >>>> I think it would be more efficient if we just staged it in source >>>>control >>>> (we wouldn¹t have to publish it to the website), and allow people to >>>> collaborate by proposing changes/patches that can be discussed and >>>>applied >>>> individually. Again, the document doesn¹t carry any weight until it is >>>> finalized and formally adopted. >>>> >>>>> Lastly, I want to address something that Taylor said in the previous >>>>> discussion: >>>>> >>>>> 'Understood. Also be aware that lazy consensus can be invoked for >>>>>code >>>>> changes by declaring so in the pull request: ³I will assume lazy >>>> consensus >>>>> on this and commit the change in X hours if there are no -1 votes.² >>>> >>>> That should have read ³days² instead of ³hours,² so it came across a >>>> little more drastic than intended... >>>> >>>>> >>>>> I think Hadoop uses lazy consensus as the default, but I¹d have to >>>> check.' >>>>> >>>>> I'm not sure where "be aware that lazy consensus can be invoked for >>>>>code >>>>> changes by declaring so in the pull request" came from. Is this a >>>>>rule >>>> that >>>>> Hadoop or other Apache projects use? Ultimately each project >>>>>determines >>>> for >>>>> themselves the rules for committing what Hadoop or other projects >>>>>do >>>> has >>>>> no relevance on Storm. This is certainly not something we ever agreed >>>>>to >>>>> for the governance of Storm. >>>> >>>> That came from here [1]. But looking at it again it seems to conflict >>>>with >>>> a RTC policy (even though some projects seem to use lazy consensus >>>>with >>>> RTC). So I stand corrected. >>>> >>>> My point is that yes, other Apache projects do use lazy consensus for >>>>code >>>> changes, so it is an option that open to us if we so choose. Nothing >>>>more. >>>> >>>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's >>>> development >>>>> has gone through some pretty ridiculous things, like the completely >>>> broken >>>>> record append implementation and the fiasco around the mapred.* and >>>>> mapreduce.* namespaces. I believe Storm to be a much higher quality >>>>>piece >>>>> of software (though not perfect, of course) and we should try keep it >>>> that >>>>> way. >>>> >>>> >>>> I never meant to imply that we should aspire to be like Hadoop. I was >>>> merely using it as an example in the context of a bylaws discussion. >>>> >>>> If there¹s on goal we all share, I think it¹s to make Storm the >>>>highest >>>> quality piece of software we can. That¹s why we¹re here. >>>> >>>> No project is perfect. We will inevitably make mistakes, fix them, >>>>learn >>>> from them, and grow stronger as a community in the process. >>>> >>>> - Taylor >>>> >>>> [1] http://www.apache.org/foundation/voting.html >>>> >>>> >>>> On Jun 27, 2014, at 8:16 PM, Nathan Marz <[email protected]> >>>>wrote: >>>> >>>>> -1 (binding) >>>>> >>>>> I've given this quite a bit of thought, and I think we need to be >>>>>more >>>>> explicit in the bylaws in a few places. >>>>> >>>>> 1. Code changes: >>>>> I've reverted a bit and think that a single +1 from any committer >>>> (besides >>>>> author of patch) and no -1's is sufficient to commit code. >>>>> >>>>> I also think we should explicitly make exceptions to these rules for >>>>> non-code related changes (e.g. documentation). In these cases we can >>>>>use >>>>> lazy consensus and the committer can use their own discretion as to >>>>>how >>>>> long the vote should be open. >>>>> >>>>> 2. Releases: >>>>> The bylaws mention a "release plan". We haven't been proposing or >>>>>voting >>>> on >>>>> release plans and I don't think that's necessary as a formal process. >>>>>I >>>>> think any committer can propose a release at any time, something >>>>>Taylor's >>>>> been doing a good job of doing. Should we just remove that from the >>>> bylaws? >>>>> >>>>> There was also discussion of allowing for "fast releases" for >>>>>important >>>>> changes that can't wait (e.g. security fixes). I am fully against >>>>>this. >>>>> Based on the previous discussion it sounds like we're in agreement >>>>>that >>>> any >>>>> committer can make unofficial releases available publicly, and this >>>>>is >>>> the >>>>> avenue we can use to get these fixes out. This way we don't commit >>>>> ourselves to any code changes or any need to maintain backwards >>>>> compatibility. >>>>> >>>>> I think the vote time for releases should be 7 days, not 3 days. A >>>> release >>>>> is a big deal and people need more time to test it and give feedback. >>>> Also, >>>>> any change to the release should require a revote. Taylor brought up >>>>>that >>>>> this could make getting a release out a pain and I agree. So I'm >>>>>fine >>>>> with including explicit exceptions in the bylaws to this rule, like >>>>>not >>>>> requiring a revote for changes to documentation, committer info in >>>> pom.xml, >>>>> etc. >>>>> >>>>> >>>>> >>>>> >>>>> Lastly, I want to address something that Taylor said in the previous >>>>> discussion: >>>>> >>>>> 'Understood. Also be aware that lazy consensus can be invoked for >>>>>code >>>>> changes by declaring so in the pull request: ³I will assume lazy >>>> consensus >>>>> on this and commit the change in X hours if there are no -1 votes." >>>>> >>>>> I think Hadoop uses lazy consensus as the default, but I¹d have to >>>> check.' >>>>> >>>>> I'm not sure where "be aware that lazy consensus can be invoked for >>>>>code >>>>> changes by declaring so in the pull request" came from. Is this a >>>>>rule >>>> that >>>>> Hadoop or other Apache projects use? Ultimately each project >>>>>determines >>>> for >>>>> themselves the rules for committing what Hadoop or other projects >>>>>do >>>> has >>>>> no relevance on Storm. This is certainly not something we ever agreed >>>>>to >>>>> for the governance of Storm. >>>>> >>>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's >>>> development >>>>> has gone through some pretty ridiculous things, like the completely >>>> broken >>>>> record append implementation and the fiasco around the mapred.* and >>>>> mapreduce.* namespaces. I believe Storm to be a much higher quality >>>>>piece >>>>> of software (though not perfect, of course) and we should try keep it >>>> that >>>>> way. >>>>> >>>>> >>>>> >>>>> On Thu, Jun 26, 2014 at 8:56 AM, Bobby Evans >>>>><[email protected] >>>>> >>>>> wrote: >>>>> >>>>>> I have updated the proposed bylaws following Nathan and Taylor¹s >>>>>> suggestions. They the only parts edited were the title to indicate >>>>>>that >>>>>> these are proposed bylaws and will not officially be adopted until >>>>>>we >>>> are a >>>>>> top level project, and the voting on code changes to reflect that a >>>>>>+1 >>>>>> from the author of the patch is not counted. >>>>>> >>>>>> You can find them here. >>>>>> >>>>>> https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md >>>>>> >>>>>> The new voting is consensus approval with (P)PMC members casting >>>>>>binding >>>>>> votes. >>>>>> >>>>>> - Bobby >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Twitter: @nathanmarz >>>>> http://nathanmarz.com >>>> >>>> >>> >>> >>> -- >>> Twitter: @nathanmarz >>> http://nathanmarz.com >> >
