-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
