0.96.0 seems to be coming along nicely. There's 10 blockers and 22criticals. Most of the blockers are being actively worked on or aresmall enough. Some of the criticals likewise and a few we could moveout. Its looking like we should be able to branch 0.96 soon. Withina month?

0.96.0 will have

+ Protobuf communications and serializations wherever HBase persists(zk, .META., HDFS other than hfiles and WALs)+ Will run on hadoop 2.0.x+ Metrics2?+ No performance regression.

What else should it have?

Anyone want to volunteer to be release manager? Otherwise, I don'tmind doing it.

> 0.96.0 seems to be coming along nicely. There's 10 blockers and 22> criticals. Most of the blockers are being actively worked on or are> small enough. Some of the criticals likewise and a few we could move> out. Its looking like we should be able to branch 0.96 soon. Within> a month?>> 0.96.0 will have>> + Protobuf communications and serializations wherever HBase persists> (zk, .META., HDFS other than hfiles and WALs)> + Will run on hadoop 2.0.x> + Metrics2?> + No performance regression.>> What else should it have?>> Anyone want to volunteer to be release manager? Otherwise, I don't> mind doing it.>> Good stuff,> St.Ack>

On Fri, Aug 24, 2012 at 11:40 AM, Ted Yu <[EMAIL PROTECTED]> wrote:> I would volunteer to be the release manager.>

You certainly have qualities that would make for a good RM; inparticular, attention to detail. Want to try a minor release beforetaking on a major? You could take on 0.92.2 and I could do 0.96.0?St.Ack

> On Fri, Aug 24, 2012 at 11:40 AM, Ted Yu <[EMAIL PROTECTED]> wrote:> > I would volunteer to be the release manager.> >>> You certainly have qualities that would make for a good RM; in> particular, attention to detail. Want to try a minor release before> taking on a major? You could take on 0.92.2 and I could do 0.96.0?> St.Ack>

Back last year when HBase master was rewritten, if I remember correctly,there were multiple people contributing significantly to the project.Stack and Jonathan Gray were the two people making the most impact on theproject.

0.96 would be the biggest milestone I have ever seen in the development ofHBase. Multiple components are being rewritten, new features coming in, etc.

Shall we entertain the idea of co-release manager ?

Just my two cents.

On Mon, Aug 27, 2012 at 2:49 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Mon, Aug 27, 2012 at 2:45 PM, Ted Yu <[EMAIL PROTECTED]> wrote:> > RM for either 0.92.2 or 0.96 is fine with me.> >>> Grand.>> I'll do 0.96.0. I can help you w/ 0.92.2 if you want.>> St.Ack>

For a major release whose feature set is so rich, co-release manager wouldhelp in the following areas:

1. tackling high priority issues - there are 11 blockers and 22 criticalissues at the moment.2. HBase has many complex components. It is beneficial for co-releasemanager(s) to take up their areas of expertise. This would expedite releaseprocess.3. co-release manager would be able to make minor releases, if the releasemanager is tied up in other work or on vacation (and there is criticalissue reported).

On Sat, Sep 8, 2012 at 9:31 PM, Ted Yu <[EMAIL PROTECTED]> wrote:> For a major release whose feature set is so rich, co-release manager would> help in the following areas:>> 1. tackling high priority issues - there are 11 blockers and 22 critical> issues at the moment.> 2. HBase has many complex components. It is beneficial for co-release> manager(s) to take up their areas of expertise. This would expedite release> process.> 3. co-release manager would be able to make minor releases, if the release> manager is tied up in other work or on vacation (and there is critical> issue reported).>> Just some initial thoughts.>

1. and 2. above are currently done by contributors. 3. is anartificial construct. Minor releases are done by release managers.If an RM is on vacation or tied up, I'd think they'd have thewherewithal to hand on the baton.

-1 on the (nebulous) co-RM notion. "Too many cooks..." etc. and we'venot had need of such a facility making larger releases than 0.96 inthe past. Projects larger than ours -- e.g. our parent, Hadoop --seemto do fine having a single RM run a release.

On Sun, Sep 9, 2012 at 10:36 AM, Stack <[EMAIL PROTECTED]> wrote:> On Sat, Sep 8, 2012 at 9:31 PM, Ted Yu <[EMAIL PROTECTED]> wrote:>> For a major release whose feature set is so rich, co-release manager would>> help in the following areas:> -1 on the (nebulous) co-RM notion. "Too many cooks..." etc. and we've> not had need of such a facility making larger releases than 0.96 in> the past. Projects larger than ours -- e.g. our parent, Hadoop --seem> to do fine having a single RM run a release.

> This depends on if the master changes that use ZK multi ops will go in as> an option that can be toggled by config, or as a replacement?>> If you run secure clusters then 3.4.5 (with ZOOKEEPER-1550) is what you> want to use regardless.>> On Tuesday, October 2, 2012, lars hofhansl wrote:>> > You mean as build time dependency, right? (Not sure now)> >> > I think we have said in the past it's not a runtime dependency.> >> > Yeah, what I was trying to say was to require ZK 3.4.4 to run HBase.> > Maybe 0.96 is too early for that, because we probably do not want to file> > more jiras against to remove now obsolete related code.> >> > -- Lars> >> >> >> > ----- Original Message -----> > From: Stack <[EMAIL PROTECTED] <javascript:;>>> > To: [EMAIL PROTECTED] <javascript:;>> > Cc: lars hofhansl <[EMAIL PROTECTED] <javascript:;>>> > Sent: Monday, October 1, 2012 3:19 PM> > Subject: Re: 0.96.0> >> > On Mon, Oct 1, 2012 at 3:10 PM, Jonathan Hsieh <[EMAIL PROTECTED]> <javascript:;>>> > wrote:> > > +1 for doing it now for 0.96.> > >> >> > We already have 3.4.4 as dependency.> >> > But sounds like we are saying that when you upgrade your hbase to> > 0.96, you need to also update your zk to 3.4.4 because hbase wants to> > use 3.4 zk features? Is that what we're saying?> >> > Good stuff,> > St.Ack> >> >>> --> Best regards,>> - Andy>> Problems worthy of attack prove their worth by hitting back. - Piet Hein> (via Tom White)>

+

Elliott Clark 2012-10-01, 23:24

NEW: Monitor These Apps!

All projects made searchable here are trademarks of the Apache Software Foundation.
Service operated by Sematext