accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 16:09:03 GMT
Inline.

On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
<billie.rinaldi@gmail.com>wrote:

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


In theory, I think this makes sense. Major releases are important enough
and difficult enough that I'd really like to require a release manager. In
practice our minors tend to be pretty significant minors that still require
a significant amount of care and preparation, so I think release managers
will still be useful.

I also think
> we should consider making the vote lazy consensus, falling back to majority
> approval if a -1 is received.
>
+0. I think shows stronger support if actually voted on up front, but this
is not a deal breaker for me. Our current process is close to this already.

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

I did not mean to suggest that this was the only thing needed to improve
our process. Simply that it is an easy solution that I expect to have
positive outcomes. While I agree that all committers should be held
responsible for driving towards a release, different people will always
have different opinions on what needs to be part of any given release. What
I think is trivial, you might consider a blocker, and vice versa. The
incomplete feature that I think needs just a little more work, you could
think is immature and should be pulled entirely. Delegating authority to a
release manager makes these decisions simpler, while still giving us
flexibility to write the code we each want.


> Some guesses for what could go on this list:
> - always select a new date when a previously selected date has passed
>
Who is responsible for this? If dates are chosen by fiat, then they quickly
become meaningless. This actually sounds like a great argument _for_ a
release manager.


> - initiate discussion of remaining tickets / tasks regularly (every week?)
>
This can be a very daunting task.


> - 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).
>
Soul searching is a very fuzzy concept that I am not comfortable with for
being used to drive releases. We've had an implicit (read: unwritten)
policy that only bug fixes can go into release branches, but many
developers (myself included) have stretched both the definition of bug and
the definition of fix. I'm completely on board with always making code
better, but it's also good to draw a line in the sand somewhere and
actually make releases.

>
> Any thoughts or other suggestions on strategies to document?
>
Maybe we can add some release plan/manager basics to the bylaws?

"""A release plan consists of:
        * a release manager
        * a proposed version number
        * a feature freeze date (bug fixes and documentation only)
        * a code freeze date (documentation only)
        * a planned rc vote date

Should any of these dates be missed, the release manager is responsible for
selecting new dates."""

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