Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> hbase 0.94.0


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
>> > <[EMAIL PROTECTED]>
>> >>>  Sent: Friday, January 27, 2012 6:11 PM
>> >>>  Subject: Re: hbase 0.94.0
>> >>>
>> >>>  Lars, Matt,
>> >>>
>> >>>  I like Matt's suggestion -- as long as it is not a burden let's
>> > keep it in.
>> >>>  If it becomes one, let's do what is best for the project.
>> >>>
>> >>>  If Cloudera needs to do the upgrade path, we'll provide one.  If it
>> > doesn't
>> >>>  go to the apache repo, we'll most likely open source it on github
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB