Re: 0.96.0

[Ted Yu <yu...@gmail.com>]

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 <st...@duboce.net> wrote:

> On Mon, Aug 27, 2012 at 2:45 PM, Ted Yu <yu...@gmail.com> 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
>

Re: 0.96.0

[Andrew Purtell <ap...@apache.org>]

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

On Sun, Sep 9, 2012 at 10:36 AM, Stack <st...@duboce.net> wrote:
> On Sat, Sep 8, 2012 at 9:31 PM, Ted Yu <yu...@gmail.com> 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)

Re: 0.96.0

[Stack <st...@duboce.net>]

On Sat, Sep 8, 2012 at 9:31 PM, Ted Yu <yu...@gmail.com> 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

Re: 0.96.0

[Ted Yu <yu...@gmail.com>]

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 <st...@duboce.net> wrote:

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

Re: 0.96.0

[Stack <st...@duboce.net>]

On Sat, Sep 8, 2012 at 6:46 AM, Ted Yu <yu...@gmail.com> wrote:
> Shall we entertain the idea of co-release manager ?
>

What is a co-release manager?
St.Ack