accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billie Rinaldi <billie.rina...@gmail.com>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 14:50:58 GMT
I disagree with Mike on point 4.  This is not a matter of people not having
authority, and I don't see a lack of release plans / managers as the
problem behind our major releases not occurring as often as we'd like.  I
wouldn't be opposed to adding a release plan / manager vote as an optional
step that can be taken when preparing for a release (perhaps a strongly
encouraged or even required step when it's a major release).  I also think
we should consider making the vote lazy consensus, falling back to majority
approval if a -1 is received.

However, adding this step will not solve our release woes.  Perhaps
something that might help would be to develop a set of suggested guidelines
to follow or strategies to take when working towards the final stages of a
release, post code freeze.  At least some of these should be
responsibilities of all committers, not just a release manager.

Some guesses for what could go on this list:
- always select a new date when a previously selected date has passed
- initiate discussion of remaining tickets / tasks regularly (every week?)
- once a .0-SNAPSHOT branch has been created, every committer should follow
some specified procedure before committing changes to it (I don't mean a
voting procedure, more like soul-searching -- or perhaps a simple
flowchart: Are you committing this change against a blocker or
documentation-only ticket? No => Don't commit or merge it to this branch).

Any thoughts or other suggestions on strategies to document?



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