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