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
signature.asc
Description: Message signed with OpenPGP using GPGMail
