accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 17:17:31 GMT
> I think it makes sense to separate the technical aspects and requirements
> of a release from a list of suggestions for the release manager (and the
> community) about how to get things done when leading up to a release (X
> can happen, and Y are some possible ways of dealing with it).

I agree. I think of it as mechanical steps, such as how to tag a release,
vs. procedural steps, like how to judge commits after feature freeze, say.

> Here's a question: should the release plan contain a list of major
features
> intended for the release?

I personally wouldn't be interested in having a feature list in the release
plan. There would already be a CHANGES doc and release notes by the end,
and the vote to start the release process would involve discussing which
features go into it.

> Should the release manager have sole responsibility for determining
> whether a major feature makes it into the release if the feature isn't
quite
> ready, or should it require a vote?

That is a good question. At least for a major release, the beginning of the
release process = feature freeze. [1] I like the idea of a vote to replan,
to cancel the current release process and start over. That could be useful
in other scenarios, like changing a target release date.

[1] http://accumulo.apache.org/governance/releasing.html

-


On Wed, Mar 12, 2014 at 12:47 PM, Billie Rinaldi
<billie.rinaldi@gmail.com>wrote:

> On Wed, Mar 12, 2014 at 8:54 AM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > The idea of "guidelines" brings to mind the Pirate Code :)
> >
> > https://www.youtube.com/watch?v=b6kgS_AwuH0
> >
> > Release guidelines do exist [1] and your suggestions seem to me good
> > additions to them.
>
>
> I think it makes sense to separate the technical aspects and requirements
> of a release from a list of suggestions for the release manager (and the
> community) about how to get things done when leading up to a release (X can
> happen, and Y are some possible ways of dealing with it).  Maybe the things
> I listed don't all fit in the latter category.
>
> Based on Mike's and Bill's discussions, I am +1 for requiring a release
> manager and plan.  I think having a release plan template is a very good
> idea, and I like Mike's suggested addition of "A release plan consists of
> ..." to the bylaws.  We're probably going to need a "release manager
> responsibilities" section at some point, but maybe not in the first draft.
>
> Here's a question: should the release plan contain a list of major features
> intended for the release?  Should the release manager have sole
> responsibility for determining whether a major feature makes it into the
> release if the feature isn't quite ready, or should it require a vote?
>
>
> > There are also some procedures defined there and
> > elsewhere [2] [3] [4] on how mechanically to do a release. However, I see
> > nothing declaring, for example:
> >
> > - that the release manager does much more than package and sign the code
> > and call votes on RCs
> > - that we pick a date for code freeze, or even use one, and what it means
> > - that we pick a target date for release
> > - what a release manager is entitled to do to get the release done
> > - how we ensure that required testing has happened
> > - who is responsible for testing
> >
> > There may be agreed-upon customs for all of the above; if so, they should
> > be codified, and more than just as guidelines. An actual plan gives us
> > rigor. We will be consistent between releases, and have a stable baseline
> > for improving over time. A plan clears up ambiguities, saying who needs
> to
> > do what, and what does not need to be done. It helps newbies like me
> > understand what's going on. It's something we can give out as a service
> to
> > the community, so that users can plan ahead, and know what we promise to
> do
> > for them.
> >
> > I wouldn't expect a release plan to be more than, as I said, a
> boilerplate
> > with filled-in blanks: RM is this person, feature freeze then, code
> freeze
> > then, release by then, everything else follows the general, standard
> rules.
> > Then lazy consensus would be a great voting choice.
> >
> > Having no plan to shoot for makes all the goal dates very soft and prone
> to
> > delay. No one knows when we'll be done and can move on. There's no
> > motivation. Overall, it doesn't make sense to me to say, "Let's not
> plan."
> > :)
> >
> > [1] http://accumulo.apache.org/governance/releasing.html
> > [2] http://accumulo.apache.org/releasing.html
> > [3] https://www.apache.org/dev/release-publishing.html
> > [4] http://www.apache.org/dev/release.html
> >
> >
> > 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).  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
> > > > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > // 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