accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 19:21:05 GMT
I always remind myself that we aren't going to run out of numbers. If some
feature doesn't make it in release X, there is always X+1. Heck, X+1 can be
just that feature for all I care. What version of Firefox or Chrome are you
using, and do you care anymore?

I want to avoid the idea that releases must be few and far between, so all
the stars must align perfectly for each. We gotta just ship. Make a plan,
pick a date, go for it, put it to bed, move on.

The idea of clamping down, especially with feature freeze, is indeed to
slow down. That is the cost for stability. The problem right now is that
it's taking weeks or months to orchestrate a release. That is too slow. You
speed it up by limiting the scope. When you get the right speed - a middle
ground between overly long and too quick - good releases can happen more
often, and then you're less likely to want to squeeze more into each

For *bug fixes* - I think they are fine after feature freeze. We should
avoid shipping bugs! :) If some huge bug appears, absolutely, postpone or
cancel the vote, we have problems to deal with. But until then, we can pick
a date, tentative as it may be. Users will be happy to see we have that
goal, so they don't have to read tea leaves. Yet, it's understood it can
change. It's not etched in stone.

On Wed, Mar 12, 2014 at 2:23 PM, Mike Drob <> wrote:

> Inline.
> On Wed, Mar 12, 2014 at 2:16 PM, Josh Elser <> wrote:
> > On 3/12/14, 12:09 PM, Mike Drob wrote:
> >
> >> - 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.
> >>
> >
> > I think I would actually prefer keeping things looser rather than having
> > to ask permission before making a fix (it just slows things down more).
> > That feels more in line with our CTR. I also don't think we've really
> had a
> > problem in this department before with changes being applied that were
> then
> > reverted (despite lines being stretched).
> >
> > I'm not concerned about the changes that get reverted. That is an example
> of the system working.
> I am more concerned about the changes that might need to be reverted, but
> then aren't. Because they're too big, or too complicated, or too messy, or
> too whatever. Or they just need a little bit more work, so don't revert
> them because I'll be done with it next week, I totally promise.
> Also, even if the only bug-fixes in release branches wasn't written down, I
> > don't think there is any ambiguity or disagreement on following that.
> >
> >
> >  >
> >>> >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."""
> >>
> >
> > A planned RC vote might be a bit aggressive. It's hard to judge whether
> or
> > not CI/RW tests will unearth some unknown bug. I like the other items,
> > though.
> >
> I put down a planned RC vote date because that seemed easier than a planned
> release date. I'd be fine with either, but really want to include a goal
> date so that people have something to shoot for once we start the process
> instead of just floundering after feature freeze.

// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

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