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 15:54:09 GMT
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. 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

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