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, 11 Mar 2014 18:17:57 GMT
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