accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [VOTE] Accumulo Bylaws
Date Tue, 18 Mar 2014 18:10:18 GMT
This vote fails with one +1 and one -1 received.


On Wed, Mar 12, 2014 at 11:45 AM, Christopher <ctubbsii@apache.org> 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 <madrob@cloudera.com> 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 <
> bhavanki@clouderagovt.com>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 <ctubbsii@apache.org>
> 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 <ctubbsii@apache.org>
> >> 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 <
> >> bhavanki@clouderagovt.com>
> >> > wrote:
> >> > >> I clarify my vote with it being the first +1 (I approve) :)
> >> > >>
> >> > >>
> >> > >> On Mon, Mar 10, 2014 at 2:29 PM, Mike Drob <madrob@cloudera.com>
> >> 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 <madrob@cloudera.com>
> >> > 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
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message