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 todd@cloudera.com designates
 209.85.215.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A8D055F4-A477-484F-909B-9B65A2319807@yahoo.com>
References: <A8D055F4-A477-484F-909B-9B65A2319807@yahoo.com>
From: Todd Lipcon <todd@cloudera.com>
Date: Sun, 11 Dec 2011 18:02:09 -0800
Message-ID: 
 <CADY20s58wc3V7yhkyG9KN3xY--7TM_cj5VCXAskyqsODh+iSyw@mail.gmail.com>
Subject: Re: Apache HBase Pow-wow Summary 11/29/2011
To: dev@hbase.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Dec 11, 2011 at 5:40 PM, Andrew Purtell <apurtell@yahoo.com> wrote:
> I was reading this with interest, since unfortunately I was not able to attend:
>
> http://www.cloudera.com/blog/2011/12/apache-hbase-pow-wow-summary-11292011/
>
> What does "BigTop parity" mean? Why should HBase not have its own criteria for attaining "1.0" status?

*BigTable parity, not BigTop.

I was the one who brought up this idea - my thinking is that, while
HBase works pretty well for many of us, it's still not at the level of
stability where a META-munching bug is a big surprise. So IMO
"BigTable parity" means we do everything described in the BigTable
paper, and we only see cases where things break "on their own" on very
rare occasion.

We're nearly there, but the number of bug fixes related to the master
between 0.90 and 0.92 implies that we're not there yet.

Of course this is just one man's opinion - we could call a vote to
release 1.0 at any point.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera