accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey+li...@cloudera.com>
Subject [DISCUSS] Accumulo Bylaw fixes
Date Tue, 11 Mar 2014 20:20:40 GMT
Moving this over to its own DISCUSS thread so we can keep the VOTE easier
to follow.

wrt #4, I'm with Mike on this. One of our big problems, as a community, is
lack of steady release cadence. Even once we decide on a feature freeze, we
don't have enough rigor in driving to release. For example, 1.6.0 hit
feature freeze 4.5 months ago[1]. I think John is doing fine given the
circumstances, but without a date to drive towards it's hard to justify
throwing stuff off the raft.

Since we'll presumably be updating the bylaws for the next vote, I'd like
to see a definition for the Release Manager role since we reference it.

[1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote

-Sean

On Tue, Mar 11, 2014 at 1: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
> > > >
>

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