Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - hbase 0.94.0


Copy link to this message
-
Re: hbase 0.94.0
Matt Corgan 2012-01-30, 20:01
I had assumed facebook had integrated HFileV2 into their 0.89 branch a
while back and that pretty much all HFiles would have been converted to v2
by now.  I guess that is not correct...
On Mon, Jan 30, 2012 at 11:53 AM, Nicolas Spiegelberg
<[EMAIL PROTECTED]>wrote:

> I think it's also good to make a crucial distinction here: it's not like
> Facebook has a concrete wide-scale upgrade strategy, these 3 points are
> deal-breakers that won't allow us to even entertain an upgrade strategy.
> This is just as critical as HDFS data loss was in 0.90: it's something we
> can't entertain & is a mandatory hurdle to trunk being considered a
> realistic option.  That said, I personally would like to upgrade our
> internal version to more closely align with other developers.  It will
> reduce our porting overhead and increase the amount of benefit we can give
> the community & visa-versa.
>
> On 1/30/12 11:46 AM, "Ted Yu" <[EMAIL PROTECTED]> wrote:
>
> >Before long term wire and format compatibility is reached, I am -0 on time
> >based release.
> >
> >As Nicolas pointed out, FB wants to migrate from 0.89-fb to 0.94
> >If we do time-based releases without wire and format compatibility, it
> >would consume a lot of our energy satisfying such requirements from
> >different companies.
> >
> >I propose wire and format compatibility as the main theme for 0.96
> >
> >Cheers
> >
> >On Mon, Jan 30, 2012 at 11:40 AM, Andrew Purtell
> ><[EMAIL PROTECTED]>wrote:
> >
> >> > Maybe the discussion should be whether 0.94 should be a time-gated or
> >> > feature-gated release? IMO we already have enough good stuff in there
> >> > on the perf front. It will be great if the checksum improvement makes
> >> > it, but if it doesn't, I'd rather have a release than delay for it.
> >>
> >>
> >> Time gated releases makes sense going forward for a few reasons, mark me
> >> down for that option.
> >>
> >>
> >> Best regards,
> >>
> >>     - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
> >>
> >> ----- Original Message -----
> >> > From: Todd Lipcon <[EMAIL PROTECTED]>
> >> > To: [EMAIL PROTECTED]
> >> > Cc: lars hofhansl <[EMAIL PROTECTED]>; Matt Corgan <
> >> [EMAIL PROTECTED]>
> >> > Sent: Monday, January 30, 2012 10:44 AM
> >> > Subject: Re: hbase 0.94.0
> >> >
> >> > On Sun, Jan 29, 2012 at 7:30 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >> >>  Initial results from HBASE-5074, support checksums in HBase block
> >> cache,
> >> >>  look promising.
> >> >>
> >> >>  Shall we discuss whether 0.94 should include it (assuming Dhruba can
> >> finish
> >> >>  the feature in Feb.) ?
> >> >
> >> > If it's a time-based release, then there's nothing to discuss. Either
> >> > it's done in time, in which case it's part of 94, or it's not, in
> >> > which case it's part of 96, right?
> >> >
> >> > Maybe the discussion should be whether 0.94 should be a time-gated or
> >> > feature-gated release? IMO we already have enough good stuff in there
> >> > on the perf front. It will be great if the checksum improvement makes
> >> > it, but if it doesn't, I'd rather have a release than delay for it.
> >> >
> >> > -Todd
> >> >
> >> >>
> >> >>  Cheers
> >> >>
> >> >>  On Fri, Jan 27, 2012 at 6:27 PM, lars hofhansl <[EMAIL PROTECTED]
> >
> >> > wrote:
> >> >>
> >> >>>  Salesforce will jumpstart with 0.94. :) Our dev cluster has the
> >> current
> >> >>>  trunk on it.
> >> >>>
> >> >>>  OK let's just add these to 0.94:
> >> >>>  HBASE-4218
> >> >>>
> >> >>>  HBASE-4608
> >> >>>  HBASE-5128
> >> >>>  script necessary to do HBASE-5293 in 0.96
> >> >>>
> >> >>>
> >> >>>  And defer the rest to 0.96, and branch 0.94 soon'ish.
> >> >>>  Do you think you can do a 0.92 and trunk version of HBASE-5128?
> >> >>>
> >> >>>  -- Lars
> >> >>>
> >> >>>
> >> >>>  ________________________________
> >> >>>   From: Jonathan Hsieh <[EMAIL PROTECTED]>
> >> >>>  To: Matt Corgan <[EMAIL PROTECTED]>
> >> >>>  Cc: lars hofhansl <[EMAIL PROTECTED]>; dev