I’m fine with posting them to the website provided that there is something front-and-center identifying the document as a draft/work-in-progress, and that they have not yet been formally adopted by the PPMC. Maybe also add something indicating that while not yet formally adopted, they are a fair reflection of the procedures the project has followed since it entered incubation.
- 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/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
signature.asc
Description: Message signed with OpenPGP using GPGMail
