I will branch this weekend.  The branch will be called 0.95 rather than
0.96.  The notion -- suggested in the past and brought up again at this
weeks dev powwow --  is that we'll put out a 0.95.0 soon and mark it
not-for-production use so folks have something to try early.  We might do
more 0.95.x releases than just the one.  We did something similar with the
0.89 set of releases that preceded 0.90.

When we think APIs and wire-format sufficiently stabilized, we'll then cut
a 0.96 from the 0.95 branch and release 0.96.0, etc., from here on out.

You all good w/ this?
Yours,
St.Ack

On Fri, Feb 22, 2013 at 12:10 PM, Stack <[EMAIL PROTECTED]> wrote:

> When we think APIs and wire-format sufficiently stabilized, we'll then cut
> a 0.96 from the 0.95 branch and release 0.96.0, etc., from here on out.
>

We need to do the client move before the branch.  Other than that sounds
good.

Hi,

To understand: we will have another branch? So trunk will be tagged 0.97 to
be released in 0.98?

Nicolas
On Fri, Feb 22, 2013 at 9:10 PM, Stack <[EMAIL PROTECTED]> wrote:

> I will branch this weekend.  The branch will be called 0.95 rather than
> 0.96.  The notion -- suggested in the past and brought up again at this
> weeks dev powwow --  is that we'll put out a 0.95.0 soon and mark it
> not-for-production use so folks have something to try early.  We might do
> more 0.95.x releases than just the one.  We did something similar with the
> 0.89 set of releases that preceded 0.90.
>
> When we think APIs and wire-format sufficiently stabilized, we'll then cut
> a 0.96 from the 0.95 branch and release 0.96.0, etc., from here on out.
>
> You all good w/ this?
> Yours,
> St.Ack
>

I am generally fine with branching.

Looking at the blocker / critical bug list for 0.96, the number of such
issues (39 as of writing of this email) increased compared to a few days
ago.
People marked their JIRAs this way so that their work gets picked up for
0.96

Considering that all the fixes for these issues would be integrated twice
once branching happens, I wonder if there should be a short buffer before
branching so that some of these high priority fixes can go in.

Just my two cents.

On Fri, Feb 22, 2013 at 12:10 PM, Stack <[EMAIL PROTECTED]> wrote:

> I will branch this weekend.  The branch will be called 0.95 rather than
> 0.96.  The notion -- suggested in the past and brought up again at this
> weeks dev powwow --  is that we'll put out a 0.95.0 soon and mark it
> not-for-production use so folks have something to try early.  We might do
> more 0.95.x releases than just the one.  We did something similar with the
> 0.89 set of releases that preceded 0.90.
>
> When we think APIs and wire-format sufficiently stabilized, we'll then cut
> a 0.96 from the 0.95 branch and release 0.96.0, etc., from here on out.
>
> You all good w/ this?
> Yours,
> St.Ack
>

On Fri, Feb 22, 2013 at 12:26 PM, Nicolas Liochon <[EMAIL PROTECTED]> wrote:

> Hi,
>
> To understand: we will have another branch? So trunk will be tagged 0.97 to
> be released in 0.98?
>

Yes.  Trunk will become 0.97-SNAPSHOT (unless someone has a better idea).
 It will follow the 0.89/0.95 pattern and will become 0.97.0 or we will
just jump to 0.98.0 on release.

St.Ack

Ok. I have some in progress jiras to be backported then. Not a big deal.

Have a nice day,

Nicolas
On Fri, Feb 22, 2013 at 9:47 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 22, 2013 at 12:26 PM, Nicolas Liochon <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
> >
> > To understand: we will have another branch? So trunk will be tagged 0.97
> to
> > be released in 0.98?
> >
>
> Yes.  Trunk will become 0.97-SNAPSHOT (unless someone has a better idea).
>  It will follow the 0.89/0.95 pattern and will become 0.97.0 or we will
> just jump to 0.98.0 on release.
>
> St.Ack
>

On Fri, Feb 22, 2013 at 12:26 PM, Ted Yu <[EMAIL PROTECTED]> wrote:

> I am generally fine with branching.
>
> Looking at the blocker / critical bug list for 0.96, the number of such
> issues (39 as of writing of this email) increased compared to a few days
> ago.
> People marked their JIRAs this way so that their work gets picked up for
> 0.96
>
> Considering that all the fixes for these issues would be integrated twice
> once branching happens, I wonder if there should be a short buffer before
> branching so that some of these high priority fixes can go in.
>

Yeah.  This is a problem.   We have been running for months w/ blockers and
criticals at about 8 and 30 count respectively and the number hasn't been
dropping. That the number has gone up because we've called for branch is
good I think because it means folks are starting to act as though 0.95/0.96
is going to happen whereas -- witness the unchanged blocker/critical count
over months -- this was not the case previously.

Regards the pain of committing in multiple places,  yeah, I think there is
no way out around it, not unless we want to put the 0.95/0.96 branch off
until, when?

Thanks,
St.Ack

bq. to put the 0.95/0.96 branch off until, when?

As Elliot indicated, HBASE-7012 'Move classes into hbase-client' should go
in. That, in turn, depends on RPC / Cell serialization to stabilize a
little bit.

Maybe branch after these patches go in ?

Again, just my personal assessment.

On Fri, Feb 22, 2013 at 12:56 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 22, 2013 at 12:26 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
> > I am generally fine with branching.
> >
> > Looking at the blocker / critical bug list for 0.96, the number of such
> > issues (39 as of writing of this email) increased compared to a few days
> > ago.
> > People marked their JIRAs this way so that their work gets picked up for
> > 0.96
> >
> > Considering that all the fixes for these issues would be integrated twice
> > once branching happens, I wonder if there should be a short buffer before
> > branching so that some of these high priority fixes can go in.
> >
>
> Yeah.  This is a problem.   We have been running for months w/ blockers and
> criticals at about 8 and 30 count respectively and the number hasn't been
> dropping. That the number has gone up because we've called for branch is
> good I think because it means folks are starting to act as though 0.95/0.96
> is going to happen whereas -- witness the unchanged blocker/critical count
> over months -- this was not the case previously.
>
> Regards the pain of committing in multiple places,  yeah, I think there is
> no way out around it, not unless we want to put the 0.95/0.96 branch off
> until, when?
>
> Thanks,
> St.Ack
>

Great!

Also like that trunk will become 0.97-SNAPSHOT soon. I have some in
progress work that I would like to propose for the ~0.98 timeframe, would
be good to land a patch against a branch for that.
On Fri, Feb 22, 2013 at 12:47 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 22, 2013 at 12:26 PM, Nicolas Liochon <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
> >
> > To understand: we will have another branch? So trunk will be tagged 0.97
> to
> > be released in 0.98?
> >
>
> Yes.  Trunk will become 0.97-SNAPSHOT (unless someone has a better idea).
>  It will follow the 0.89/0.95 pattern and will become 0.97.0 or we will
> just jump to 0.98.0 on release.
>
> St.Ack
>

--
Best regards,

   - Andy

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

+1 for the proposal, including, branching, and the branch names.

Enis
On Fri, Feb 22, 2013 at 1:20 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> Great!
>
> Also like that trunk will become 0.97-SNAPSHOT soon. I have some in
> progress work that I would like to propose for the ~0.98 timeframe, would
> be good to land a patch against a branch for that.
>
>
> On Fri, Feb 22, 2013 at 12:47 PM, Stack <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Feb 22, 2013 at 12:26 PM, Nicolas Liochon <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Hi,
> > >
> > > To understand: we will have another branch? So trunk will be tagged
> 0.97
> > to
> > > be released in 0.98?
> > >
> >
> > Yes.  Trunk will become 0.97-SNAPSHOT (unless someone has a better idea).
> >  It will follow the 0.89/0.95 pattern and will become 0.97.0 or we will
> > just jump to 0.98.0 on release.
> >
> > St.Ack
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

On Fri, Feb 22, 2013 at 12:25 PM, Elliott Clark <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 22, 2013 at 12:10 PM, Stack <[EMAIL PROTECTED]> wrote:
>
> > When we think APIs and wire-format sufficiently stabilized, we'll then
> cut
> > a 0.96 from the 0.95 branch and release 0.96.0, etc., from here on out.
> >
>
> We need to do the client move before the branch.  Other than that sounds
> good.
>
You waiting on me (rpc) Elliott?  If so, don't I'd say.  I can rebase no
problem and I don't see the last part of the rpc going in until it has had
a good bit more review and a bit of profiling done.

Agree would be nice getting client refactor in before branch.  Its a big
code move.

St.Ack

I'll try and get that to you tonight or at least this weekend so you can
branch on schedule.
On Feb 22, 2013 4:30 PM, "Stack" <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 22, 2013 at 12:25 PM, Elliott Clark <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Feb 22, 2013 at 12:10 PM, Stack <[EMAIL PROTECTED]> wrote:
> >
> > > When we think APIs and wire-format sufficiently stabilized, we'll then
> > cut
> > > a 0.96 from the 0.95 branch and release 0.96.0, etc., from here on out.
> > >
> >
> > We need to do the client move before the branch.  Other than that sounds
> > good.
> >
>
>
> You waiting on me (rpc) Elliott?  If so, don't I'd say.  I can rebase no
> problem and I don't see the last part of the rpc going in until it has had
> a good bit more review and a bit of profiling done.
>
> Agree would be nice getting client refactor in before branch.  Its a big
> code move.
>
> St.Ack
>

+1 on branching now. Otherwise we'll find new "excuses" to delay it further.

That said, maybe Elliot's client move can be accommodated before we branch(?)

________________________________
 From: Stack <[EMAIL PROTECTED]>
To: HBase Dev List <[EMAIL PROTECTED]>
Sent: Friday, February 22, 2013 12:56 PM
Subject: Re: Heads-up! Branching 0.96 (actually 0.95) this weekend
 
On Fri, Feb 22, 2013 at 12:26 PM, Ted Yu <[EMAIL PROTECTED]> wrote:

> I am generally fine with branching.
>
> Looking at the blocker / critical bug list for 0.96, the number of such
> issues (39 as of writing of this email) increased compared to a few days
> ago.
> People marked their JIRAs this way so that their work gets picked up for
> 0.96
>
> Considering that all the fixes for these issues would be integrated twice
> once branching happens, I wonder if there should be a short buffer before
> branching so that some of these high priority fixes can go in.
>

Yeah.  This is a problem.   We have been running for months w/ blockers and
criticals at about 8 and 30 count respectively and the number hasn't been
dropping. That the number has gone up because we've called for branch is
good I think because it means folks are starting to act as though 0.95/0.96
is going to happen whereas -- witness the unchanged blocker/critical count
over months -- this was not the case previously.

Regards the pain of committing in multiple places,  yeah, I think there is
no way out around it, not unless we want to put the 0.95/0.96 branch off
until, when?

Thanks,
St.Ack

I'm +1 for branching sooner rather than later, (it was supposed to happen
today?)  and with the numbering scheme.  It will cause some pain for
committers with things in flight, but it always will for something, and as
long as this stuff gets in soon it isn't too onerous.

Jon.

On Fri, Feb 22, 2013 at 9:58 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> +1 on branching now. Otherwise we'll find new "excuses" to delay it
> further.
>
> That said, maybe Elliot's client move can be accommodated before we
> branch(?)
>
>
>
> ________________________________
>  From: Stack <[EMAIL PROTECTED]>
> To: HBase Dev List <[EMAIL PROTECTED]>
> Sent: Friday, February 22, 2013 12:56 PM
> Subject: Re: Heads-up! Branching 0.96 (actually 0.95) this weekend
>
> On Fri, Feb 22, 2013 at 12:26 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
> > I am generally fine with branching.
> >
> > Looking at the blocker / critical bug list for 0.96, the number of such
> > issues (39 as of writing of this email) increased compared to a few days
> > ago.
> > People marked their JIRAs this way so that their work gets picked up for
> > 0.96
> >
> > Considering that all the fixes for these issues would be integrated twice
> > once branching happens, I wonder if there should be a short buffer before
> > branching so that some of these high priority fixes can go in.
> >
>
> Yeah.  This is a problem.   We have been running for months w/ blockers and
> criticals at about 8 and 30 count respectively and the number hasn't been
> dropping. That the number has gone up because we've called for branch is
> good I think because it means folks are starting to act as though 0.95/0.96
> is going to happen whereas -- witness the unchanged blocker/critical count
> over months -- this was not the case previously.
>
> Regards the pain of committing in multiple places,  yeah, I think there is
> no way out around it, not unless we want to put the 0.95/0.96 branch off
> until, when?
>
> Thanks,
> St.Ack
>

--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]

You the man Elliott.  This is a big code move  so would be good to have
this side of the branch.  If you can't do it on the w/e, we can do it
post-branch too.

Thanks,
St.Ack
On Fri, Feb 22, 2013 at 6:25 PM, Elliott Clark <[EMAIL PROTECTED]> wrote:

> I'll try and get that to you tonight or at least this weekend so you can
> branch on schedule.
> On Feb 22, 2013 4:30 PM, "Stack" <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Feb 22, 2013 at 12:25 PM, Elliott Clark <[EMAIL PROTECTED]>
> wrote:
> >
> > > On Fri, Feb 22, 2013 at 12:10 PM, Stack <[EMAIL PROTECTED]> wrote:
> > >
> > > > When we think APIs and wire-format sufficiently stabilized, we'll
> then
> > > cut
> > > > a 0.96 from the 0.95 branch and release 0.96.0, etc., from here on
> out.
> > > >
> > >
> > > We need to do the client move before the branch.  Other than that
> sounds
> > > good.
> > >
> >
> >
> > You waiting on me (rpc) Elliott?  If so, don't I'd say.  I can rebase no
> > problem and I don't see the last part of the rpc going in until it has
> had
> > a good bit more review and a bit of profiling done.
> >
> > Agree would be nice getting client refactor in before branch.  Its a big
> > code move.
> >
> > St.Ack
> >
>

All the big code moves are done.  Let me branch now.
On Fri, Feb 22, 2013 at 10:34 PM, Stack <[EMAIL PROTECTED]> wrote:

> You the man Elliott.  This is a big code move  so would be good to have
> this side of the branch.  If you can't do it on the w/e, we can do it
> post-branch too.
>
> Thanks,
> St.Ack
>
>
> On Fri, Feb 22, 2013 at 6:25 PM, Elliott Clark <[EMAIL PROTECTED]> wrote:
>
>> I'll try and get that to you tonight or at least this weekend so you can
>> branch on schedule.
>> On Feb 22, 2013 4:30 PM, "Stack" <[EMAIL PROTECTED]> wrote:
>>
>> > On Fri, Feb 22, 2013 at 12:25 PM, Elliott Clark <[EMAIL PROTECTED]>
>> wrote:
>> >
>> > > On Fri, Feb 22, 2013 at 12:10 PM, Stack <[EMAIL PROTECTED]> wrote:
>> > >
>> > > > When we think APIs and wire-format sufficiently stabilized, we'll
>> then
>> > > cut
>> > > > a 0.96 from the 0.95 branch and release 0.96.0, etc., from here on
>> out.
>> > > >
>> > >
>> > > We need to do the client move before the branch.  Other than that
>> sounds
>> > > good.
>> > >
>> >
>> >
>> > You waiting on me (rpc) Elliott?  If so, don't I'd say.  I can rebase no
>> > problem and I don't see the last part of the rpc going in until it has
>> had
>> > a good bit more review and a bit of profiling done.
>> >
>> > Agree would be nice getting client refactor in before branch.  Its a big
>> > code move.
>> >
>> > St.Ack
>> >
>>
>
>