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

I like the notion of cutting 0.96 RC in a month.

I would volunteer to be the release manager.

Cheers

On Fri, Aug 24, 2012 at 11:35 AM, Stack <[EMAIL PROTECTED]> wrote:

> 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; 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

RM for either 0.92.2 or 0.96 is fine with me.

BTW Lars H, e.g., directly manages a major release without going through
minor release.

Cheers

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

> 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
>

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

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 the
project.

0.96 would be the biggest milestone I have ever seen in the development of
HBase. 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
>

On Sat, Sep 8, 2012 at 6:46 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> Shall we entertain the idea of co-release manager ?
>

What is a co-release manager?
St.Ack

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.

On Sat, Sep 8, 2012 at 9:13 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Sat, Sep 8, 2012 at 6:46 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > Shall we entertain the idea of co-release manager ?
> >
>
> What is a co-release manager?
> St.Ack
>

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 an
artificial construct.  Minor releases are done by release managers.
If an RM is on vacation or tied up, I'd think they'd have the
wherewithal to hand on the baton.

-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.

St.Ack

I agree, -1. Let's keep "management engineering" to a minimum.

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.

--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)

That last little bit of Metrics migration to Metrics2 (hbase-4050) should
probably go in so that we're not straddling the different versions.

On Mon, Oct 1, 2012 at 3:38 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> 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)
>