accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Thu, 13 Mar 2014 16:21:10 GMT
On Tue, Mar 11, 2014 at 4:20 PM, Sean Busbey <busbey+lists@cloudera.com>wrote:

> 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.
>

I have been reading through a lot of the comments made so far.

A release manger is a possible solution to the problem of releases
languish.   I think it would be help to list what are causing releases to
languish..

1.  Incomplete features checked in before feature freeze
2. A steady of stream of non-essential changes after feature freeze
3. Testing takes a while and has to be redone after major changes are made
4. Critical bugs found during test need to be fixed

What else other things are slowing down releases?

I am not convinced a release manager can solve these problems, my main
concern is scalability.   The 1.7.0 release manager would have to really be
on top of all of the 1.7.0 commits, even before feature freeze.  If the
release manager does not deal w/ incomplete features early, it will be much
harder to deal with them later.  W/ CTR commits can come in faster than the
release manager can process them.   This make me think of the benevelont
dictator model where only the 1.7.0 RM merges things into 1.7.0-SNAPSHOT.
They can do this as they have time.   I have been looking at Gerrit a bit
lately.  I have never used it, but I like what I have read.  It seems like
gerrit is better than RB because its more automated w/ less friction.
Using Gerrit and RTC would be more scalable than a single RM.


> [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