Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of saint.ack@gmail.com
 designates 209.85.221.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=X2tCFNK5qnG1f1IRfww4PCoKQKQ+SP8d4eU7h0jutrc1zlJ5WBKWDxeCqL4+nWPXHi
         RJGSpaVvhWw86/LkVX2CU7fJm+r9tRO6jI3Rn7YrPSLWizHbGIeJWJkoca0Da4DPTLAR
         8RRUXS4dMa5g7FrCtpQYPBGRwSvSu46GC8SG8=
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: <AANLkTik6yORhRVCngpHwceiCADCuVwgZc9wZIn4HQ04S@mail.gmail.com>
References: <AANLkTik6yORhRVCngpHwceiCADCuVwgZc9wZIn4HQ04S@mail.gmail.com>
Date: Thu, 20 May 2010 12:10:15 -0700
Message-ID: <AANLkTimI_-JO3f3Uku1haXKIRCeeAhqAABRIyKvtjOQC@mail.gmail.com>
Subject: Re: Development release series?
From: Stack <stack@duboce.net>
To: dev@hbase.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 as long as we are super clean on the messaging about how these dev
releases differ from what we usually put out (#3 in the below).  Also,
we need to be clear that these dev releases are driving toward the
next major release of hbase and will stop when that is published.

#4 in the below, does it apply to migration?  Should we gurantee that
evrelease#103 will always be able to run atop the data written with
devrelease#102?  Lets not guarantee no-migration because 1.) I don't
think it'll be an issue w/ this coming release -- no big data format
changes planned -- and 2.) migrations are time-consuming, a
distraction from forward dev (Its unlikely that the characters who
depend on a migration working will be playing w/ dev-releases
anyways).

One healthy development I see coming of this is that it'll spur the
development of release evaluation tools and tests.

You don't have to volunteer as release manager Todd.  Your time would
be better served bug fixing (smile).

St.Ack

On Thu, May 20, 2010 at 10:30 AM, Todd Lipcon <todd@cloudera.com> wrote:
> Hi all,
>
> I've been throwing this idea around to a few people individually over the
> last week, but wanted to raise it on the list for a wider discussion:
>
> I'd like to propose inserting a "development release series" in between 0=
.20
> and our next release (the one that will have full durability, significant
> master fixup, etc). In terms of what this release series would be:
>
> 1) Frequent Releases. We should try to do a release once a month between =
now
> and the next major release.
>
> 2) Low Amount of QA. We should not make any guarantees that the releases
> have been heavily tested. They should certainly pass unit tests and basic
> functional tests (eg PE and other cluster smoke tests) but we would not g=
o
> through multi-week rc cycles.
>
> 3) Clearly communicated "Development" status. We do not want new users on
> this release unless they are aware they are trying what is essentially a
> trunk snapshot. We should feel free to have serious known bugs in these
> development releases and not address them until the next release.
>
> 4) Given the "development" status of this build, I think we should drop t=
he
> "no breaking changes between point releases" restriction. That way we're
> fine to make RPC/API fixups as the series progresses.
>
> 5) Normal policies regarding license cleanliness, release voting, etc. =
=A0Kind
> of goes without saying, but we still need to be careful to maintain prope=
r
> licensing, etc, and not let anything slip in that would be Apache 2
> incompatible, etc.
>
> Now, the reasons I am proposing this:
>
> 1) We have a vibrant user/contributor community which has a diverse set o=
f
> workloads. The core developer community has a smaller (but growing) set o=
f
> workloads. There have been a few cases where a release has worked great f=
or
> the workloads of the core team, but after a release we've found a serious
> bug that only affects some feature or access pattern that hasn't been
> sufficiently tested during development. Doing frequent development releas=
es
> gives reasonable milestones for users to try upcoming releases for their
> workloads and give feedback if there has been a regression.
>
> Two particular examples of the above are the ExplicitColumnTracker infini=
te
> loop bug in 0.20.4, and the META caching regression in 0.20.3.
>
> 2) Given the recent switch to Maven, I think we will find that the first
> post-maven release will bring new difficulties we haven't worked through =
in
> the past. We should make sure we know how to release off the new build
> system, and that all of the various shell scripts and integration points
> still work. Doing some "practice" releases before the real thing will all=
ow
> us to start tackling these problems early.
>
> 3) It's been quite some time since the last major release. Doing a fast
> progression of a few development releases is a good way to highlight the
> recent surge of HBase development and build anticipation for what's comin=
g.
>
> 4) On a selfish note, I would like to attempt to include a "beta" release=
 of
> durable HBase packaged in CDH3 in June. We will certainly not be ready fo=
r
> the next major release at that point. I can certainly pick an svn revisio=
n
> and build my own release off that, but if the version number in CDH lines=
 up
> with a version number of this development series, I think it will present
> less user confusion, etc.
>
> I am also happy to volunteer myself to release manage at least the first =
of
> this series. Though I do not have committer access, the Apache rules
> generally allow anyone to propose a release tarball, so long as it's vote=
d
> on by the PMC.
>
> Thanks
> -Todd
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>