OK I am canceling the VOTE, I will update the document following Nathan and Taylor¹s requests and restart the vote after I have found time to make the changes.
- Bobby On 6/23/14, 6:03 PM, "P. Taylor Goetz" <[email protected]> wrote: >I just took another look and realized that "(Proposed)" is in the main >title. > >I'm +1 for adding it to the website. But I would like to see some text >explaining that it is a WIP modeling the process we've followed thus far. > >-Taylor > >> On Jun 23, 2014, at 1:12 PM, Bobby Evans <[email protected]> >>wrote: >> >> 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/84d297a23c05fef5164029bd4 >>b >> 697071aa349f9c/BYLAWS.md >> >> I only updated the formatting from the original proposal as you can see >> here >> >> >> >>https://github.com/revans2/incubator-storm/commit/84d297a23c05fef5164029b >>d >> 4b697071aa349f9c#diff-77abd199a39cb67711132cd27fe41f6b >> >> - Bobby >> >> >> >> >> >> -- >> Twitter: @nathanmarz >> http://nathanmarz.com >>
