This vote fails with one +1 and one -1 received.
On Wed, Mar 12, 2014 at 11:45 AM, Christopher <[email protected]> wrote: > 1) Is the list both comprehensive and compulsory? Are these actions > ones which require a vote? If so, that should be clarified. > > 2) Then we should remove actions that describe reinstatement, as they > make no sense if removal is not possible. > > 3) Mike's language seems reasonable. > > 4) See forked thread for detailed discussion, but in short, I agree > with the value of having a release manager. The question is whether or > not it requires a vote, since it's a brand new thing. This is related > to #1 above. I think it's safe to say that there is not yet consensus > that this action should require a vote, so if the actions listed are > intended to indicate those actions for which a vote is required, then > we should omit this for the acceptance of the initial bylaws. I also > think that "release plan" is ill-defined here, so it's hard to make > voting to establish one mandatory. We can always add it later (and I'd > probably be in favor of doing so), pending the results of the detailed > discussions in the forked thread, but I'd hate to have that one action > hold up the initial bylaws, so I don't think it should be included in > the first version. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Tue, Mar 11, 2014 at 2:17 PM, Mike Drob <[email protected]> wrote: > > 1) Agree w/ Bill. > > > > 2) Agree w/ Bill. > > > > 3) In my understanding, codebase includes the site svn, the primary git > > repository, and all contrib repositories. Adoption of a new codebase > > generally refers to the creation of a new contrib repository. However, I > > could see it also expanded to cover things like re-doing the entire site > > look and feel, or merging a contrib project into the primary codebase. > > Christopher, do you have any proposed verbiage that you would like to see > > specifically? > > > > 4) I very much disagree, Christopher. Having a dedicated release manager > is > > critical to having a release occur in a timely manner. Further, the > > community needs to be able to make hard decisions, like setting a feature > > or code freeze date, or pulling incomplete work out of a branch. Right > now, > > we have release managers in name only, and I would love to see us give > them > > more authority on performing the release - right now we have a steady > > stream of small changes that developers feel should be exempt from the > > freeze, something I'm guilty of myself as well. I see the lack of a > > formalized release plan as one reason for why releases tend to drag on > for > > far too long. > > > > In short, if we don't have a release manager pushing for them, then > > releases just won't happen. It's a gruelling task, and we need to have > > procedure to bless somebody to do it. > > > > > > Mike > > > > > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki < > [email protected]>wrote: > > > >> My sense from the conversations leading up to the vote: > >> > >> 1) I believe the list is comprehensive, in that no other voting actions > are > >> contemplated. If we realize we need a new one, we can add it later. > >> > >> 2) We determined that a committer, by ASF rules, cannot truly lose > >> committer status [1], so no removal procedure is defined. Removal of a > PMC > >> member is up to the ASF Board [2], so no procedure is defined. > >> > >> 3) I see no harm in adding a definition. > >> > >> 4) I think the "release plan" is the process for cutting a release, > while > >> "product release" is for approving a specific RC as the release. For > me, a > >> boilerplate release plan with customizations (who is the RM, what tests > are > >> needed, time frame for freezes, etc.) would be nice to have laid out. > >> > >> [1] http://www.apache.org/dev/committers.html#committer-set-term > >> [2] http://www.apache.org/dev/pmc.html#pmc-removal > >> > >> > >> On Mon, Mar 10, 2014 at 5:52 PM, Christopher <[email protected]> > wrote: > >> > >> > Since I didn't technically vote, I guess I will now: > >> > I'm going to give it a -1, pending the resolution the following > >> > issues, and for an opportunity to correct the minor punctuation/typos. > >> > > >> > Specifically, I'd like these addressed before I change my vote: > >> > 1) clarification of whether the ACTIONS list is comprehensive > >> > 2) clarify reinstatement in the absence of a lack of removal > procedures > >> > 3) codebase defined (or at least, Adoption of New Codebase clarified) > >> > 4) remove "release plan" as requiring a vote (or discuss), because > >> > while it is nice to coordinate release candidates through a release > >> > manager, I'm not sure it should be strictly necessary that release > >> > candidates be planned, or limited to that release manager. > >> > > >> > > >> > -- > >> > Christopher L Tubbs II > >> > http://gravatar.com/ctubbsii > >> > > >> > > >> > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <[email protected]> > >> wrote: > >> > > ***Punctuation: > >> > > > >> > > PMC section: > >> > > "PMC from a Foundation perspective is" -> "PMC, from a Foundation > >> > > perspective, is" > >> > > "Secondly " -> "Secondly, " > >> > > "long term" -> "long-term" > >> > > "not coding - but to ensure" -> "not coding, but to ensure" > >> > > "Within the ASF we worry" -> "Within the ASF, we worry" > >> > > > >> > > VETOES section (comma): > >> > > "veto - merely that" -> "veto, merely that" > >> > > > >> > > ***Typos: > >> > > > >> > > APPROVALS section (typo): > >> > > "that -1 votes" -> "than -1 votes" > >> > > > >> > > ***Definitions: > >> > > I would like to see "codebase" defined. It's used throughout, but is > >> > > never clearly defined... particularly in the "Adoption of New > >> > > Codebase" section of the ACTIONS section. > >> > > > >> > > ***Other: > >> > > In the ACTIONS section, it describes reinstatement actions, but not > >> > > removal actions, so it's not clear what reinstatement means. > >> > > > >> > > It should also be made clear that the ACTIONS section is not a > >> > > comprehensive list of actions. > >> > > > >> > > I'm also not sure that the "Release plan" should require a vote, as > >> > > this seems covered by the "Product release" situation. The other > >> > > actions seem to imply a vote is required for that action. Are we > >> > > saying that planning to release requires a vote? If so, I can get on > >> > > board... I just don't remember that happening in the past, so this > >> > > isn't so much a formalization of our existing practices, but also > >> > > establishing a new one as well. And, in this case, I'm not sure it's > >> > > one we need. > >> > > > >> > > -- > >> > > Christopher L Tubbs II > >> > > http://gravatar.com/ctubbsii > >> > > > >> > > > >> > > On Mon, Mar 10, 2014 at 2:38 PM, Bill Havanki < > >> [email protected]> > >> > wrote: > >> > >> I clarify my vote with it being the first +1 (I approve) :) > >> > >> > >> > >> > >> > >> On Mon, Mar 10, 2014 at 2:29 PM, Mike Drob <[email protected]> > >> wrote: > >> > >> > >> > >>> Was pointed out an error in the vote descriptions. They should be: > >> > >>> > >> > >>> [ ] +1 - "I approve of these proposed bylaws and accept them for > the > >> > Apache > >> > >>> Accumulo project" > >> > >>> [ ] +0 - "I neither approve nor disapprove of these bylaws, but > >> accept > >> > them > >> > >>> for the Apache Accumulo project" > >> > >>> [ ] -1 - "I do not approve of these proposed bylaws and do not > accept > >> > them > >> > >>> for the Apache Accumulo project because..." > >> > >>> > >> > >>> Obviously, everybody has a choice when they're voting. :) > >> > >>> > >> > >>> > >> > >>> On Mon, Mar 10, 2014 at 2:23 PM, Mike Drob <[email protected]> > >> > wrote: > >> > >>> > >> > >>> > Please vote on the proposed bylaws, as available at > >> > >>> > > >> > >>> > >> > > >> > https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1574615&view=markup > >> > >>> > > >> > >>> > A nicer to read version is available at > >> > >>> > http://accumulo.apache.org/bylaws.html > >> > >>> > > >> > >>> > This vote will be open for 7 days, until 17 March 18:15 UTC. > >> > >>> > > >> > >>> > Upon successful completion of this vote, the first line of the > >> > document > >> > >>> > body will be replaced with "This is version 1 of the bylaws." > >> > >>> Additionally, > >> > >>> > and a link will be added to this document on the nav-bar on the > >> left. > >> > >>> > > >> > >>> > This vote requires majority approval to pass: at least 3 +1 > votes > >> and > >> > >>> more > >> > >>> > +1 than -1's. > >> > >>> > > >> > >>> > Mike > >> > >>> > > >> > >>> > [ ] +1 - "I approve of these proposed bylaws and accept them for > >> the > >> > >>> > Apache Accumulo project" > >> > >>> > [ ] +0 - "I neither approve nor disapprove of these bylaws, but > >> > accept > >> > >>> > them for the Apache Accumulo project" > >> > >>> > [ ] +1 - "I do not approve of these proposed bylaws and do not > >> accept > >> > >>> them > >> > >>> > for the Apache Accumulo project because..." > >> > >>> > > >> > >>> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> // Bill Havanki > >> > >> // Solutions Architect, Cloudera Govt Solutions > >> > >> // 443.686.9283 > >> > > >> > >> > >> > >> -- > >> // Bill Havanki > >> // Solutions Architect, Cloudera Govt Solutions > >> // 443.686.9283 > >> >
