I put BYLAWS.md on a github branch to track changes to them during the vote, and because github will display them cleanly. I don’t think they should be in the same repo as the source code long term, as their lifecycle is completely different. I was going to move them over to the subversion web page repo once the vote passed.
My goal with this was to start with a base set of bylaws that were not contentious, because that is how we had been unofficially managing the project, and then discuss/vote on other more contentious changes. I don’t think the exact time frame of when we officially adopt the bylaws really changes that process. - Bobby From: "P. Taylor Goetz" <[email protected]<mailto:[email protected]>> Reply-To: <[email protected]<mailto:[email protected]>> Date: Monday, June 23, 2014 at 11:29 AM To: <[email protected]<mailto:[email protected]>> Subject: Re: [VOTE] Storm Bylaws Maybe we should consider canceling this vote and re-wording it a bit. The graduation resolution template implies that bylaws are adopted during graduation: > RESOLVED, that the initial Apache ${PROJECT} PMC be and hereby is > tasked with the creation of a set of bylaws intended to > encourage open development and increased participation in the > Apache ${PROJECT} Project; and be it further Even though Bobby specifically mentioned adopting the bylaws, that’s not really how I looked at this proposal. I see it more as a proposal to pull the document Bobby put together into source control as a working draft so we can track changes, and vote on proposed changes as we move toward graduation (when we would formally adopt the final draft). If this is the approach we decide to take, it would probably be best to add a prominent header identifying the document as a WORKING DRAFT. See additional comments in-line below. - Taylor On Jun 20, 2014, at 3:29 PM, Nathan Marz <[email protected]<mailto:[email protected]>> wrote: First off – it doesn't make sense to use the voting rules in the bylaws we're voting on as we haven't adopted the bylaws yet. I think that forming the initial set of bylaws should require consensus approval. We don't have that many PPMC members that this is going to hold us back, and I think it's important that we're all in complete agreement on the bylaws moving forward. Obviously if we agree to this set of bylaws than future changes can be accomplished with lazy 2/3 majority. A few things: - Code changes should be two +1's from committers other than the one who authored the patch, and no -1's. I don't think a case where only a single +1 is needed to get a change committed allows for sufficient review. This is also the rule we all agreed to in the move to Apache and also before. 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. Remember too that all our code is under source control and any mistaken or misguided commit can easily be rolled back. - I think keeping the roles of PMC member and committer separate in the bylaws is fine. I can see how having a PMC that's too big could slow down a project, so I can see how we'll reach a point where we'll want to propose people as committers and not PMC members. I don't think having this distinction in the bylaws in any way slows down the project, as we can just propose people to be both committers and PMC members as we have been all along. Agreed. Lets keep them separate and continue using the committer+PPMC member convention when proposing new members. We can decide later, or on a case-by-case basis if we want to deviate from this convention. - It's true that there are certain cases where we'd want to get changes in quickly (e.g. security fix). However, making mechanisms for getting things in quickly would also make it possible to get things in that haven't been sufficiently reviewed and could be detrimental to the project. An alternative is to not change any of the processes for making official Storm releases, and instead make alternative pathways to make "unofficial" releases based on work that hasn't been fully vetted through the normal process. These releases would have the caveat that whatever is in them could change or be removed in a future release. This way we can get things out to the community quickly if need be, but make sure that nothing gets into a permanent release that hasn't been properly vetted. The process for "emergency release" could be something like lazy consensus over a 1 day vote, or maybe one +1 and no -1's over a 1 day vote. Those releases would be tagged something like 0.9.2-hotfix1, and an emergency release would be followed by a normal vote as to whether to do an official release with those changes. We’re pretty much already doing lot of this today. For example with the security branch I periodically make builds available via my people.a.o account for convenience. Obviously they are not official releases and do not get distributed through dist.a.o. We can do this at any time. Also remember that when we vote on releases, we’re really just voting on a release *candidate*. The votes can always be cancelled and/or vetoed and a new release candidate/vote issued. Only when an RC has been officially approved can artifacts be released through official channels. - I do not think we should try to make a distinction between "minor" changes to a release and "normal" changes that do or do not require a re-vote. How are we really going to come up with a definition of "minor" that's not ambiguous? I don't see there being any rush to getting releases out a couple days earlier, and I view it as far more important to ensure that sufficient review is done such that we don't release something bad to the community. Even "minor" changes can go horribly wrong, as I'm sure we've all experienced before. So everything should be properly vetted and any changes should require a re-vote. As stated in the prior point I think we can have separate pathways for "emergency" releases that are distinct from normal releases. I mainly consider “minor” changes from a release management perspective — changes that do not alter any source code (.java, .clj, .js, .py, etc.). Real-world examples of “minor” changes: - updating CHANGELOG.md when merging pull requests. - adding new committer information to the parent pom.xml. - updating the maven-release-plugin to 2.5 to fix an issue that prevented the plugin from properly creating a release. - rolling back a botched release attempt (resetting version numbers in poms, deleting tags, etc.) - fixing links in the README that pointed to the old wiki - updating the contributor list All of these require git commits. None of them alter the runtime characteristics of the software. If we required a 2+ day approval for these things our daily/release workflow would grind to a halt. See also my previous comment about rolling back wayward changes. If things go horribly wrong, the change that caused it can be reverted. Finally, the release DISCUSS and VOTE threads are the final protection from releasing something bad to the community. As such, I would hope that all committers do their best to participate in the discussions and help vet everything that goes into a release. On Fri, Jun 20, 2014 at 10:16 AM, Andy Feng <[email protected]<mailto:[email protected]>> wrote: +1 On 6/20/14, 6:05 AM, "Bobby Evans" <[email protected]<mailto:[email protected]>> wrote: I got almost no feedback on the bylaws. I am hoping everyone thought they were a good idea and not that the document was so long that few bothered to read it. Either way I am calling a vote on the bylaws. In accordance with the proposed bylaws the vote will run for 7 days ending Friday June 27th, and will require at least 3 +1s from active (P)PMC members with at least twice as many +1s as -1s. Others in the community are encouraged to vote as well to let your opinion be known, even if your vote is not binding. If the vote passes I'll update the storm web page to include the bylaws. I am +1 (binding) You can find the markdown formatted bylaws at https://github.com/revans2/incubator-storm/blob/84d297a23c05fef5164029bd4b 697071aa349f9c/BYLAWS.md I only updated the formatting from the original proposal as you can see here https://github.com/revans2/incubator-storm/commit/84d297a23c05fef5164029bd 4b697071aa349f9c#diff-77abd199a39cb67711132cd27fe41f6b - Bobby -- Twitter: @nathanmarz http://nathanmarz.com
