Hi devs,

I think we should release 0.90.3 pretty soon, it already has 30 fixed
bugs including 4 blockers and a good bunch of nice to have
fixes/improvements.

Since there are no other blockers we could build a RC right now but it
seems there's a few more jiras[1] that could be quickly resolved.

This is why I'm asking all devs to review the jiras that are still
opened against 0.90.3 and to either add a fix or punt.

Thank you,

J-D
1. https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%220.90.3%22+AND+project+%3D+HBASE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC

Can we get HBASE-3777 into 0.90.3 ?

On Tue, May 3, 2011 at 2:10 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]>wrote:

> Hi devs,
>
> I think we should release 0.90.3 pretty soon, it already has 30 fixed
> bugs including 4 blockers and a good bunch of nice to have
> fixes/improvements.
>
> Since there are no other blockers we could build a RC right now but it
> seems there's a few more jiras[1] that could be quickly resolved.
>
> This is why I'm asking all devs to review the jiras that are still
> opened against 0.90.3 and to either add a fix or punt.
>
> Thank you,
>
> J-D
>
>
> 1.
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%220.90.3%22+AND+project+%3D+HBASE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
>

It's a pretty big change and it would need to be backported, but I
understand your concern.

In my ideal world, 0.92.0 would be released in not too long and this
would be a non-issue.

In the real world, for all I know, 0.92.0 could be released in 6
months or more and people would be struggling with ZK connection
errors during all that time (and we would tell them to patch their
0.90 themselves).

Here's what I propose:

 - Release 0.90.3 without HBASE-3777 since it already has enough going
and it's almost ready to go out.
 - Backport HBASE-3777 and post the patch in that jira, considering
that the 0.90 branch won't be changing a lot in the foreseeable future
so it should apply cleanly for some time.
 - Point people to that patch and ask them to try it out on 0.90, I
know for sure that we'll we doing it here.
 - In the mean time, the patch will get more usage in trunk as we
prepare a 0.92 release and might find issues.
 - Finally consider patching it in for 0.90.4 if we have enough
confidence in it (with or without some other fixes that we would have
figured out by then).

Does that sound good to you?

Thx,

J-D

On Tue, May 3, 2011 at 2:20 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> Can we get HBASE-3777 into 0.90.3 ?
>
> On Tue, May 3, 2011 at 2:10 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]>wrote:
>
>> Hi devs,
>>
>> I think we should release 0.90.3 pretty soon, it already has 30 fixed
>> bugs including 4 blockers and a good bunch of nice to have
>> fixes/improvements.
>>
>> Since there are no other blockers we could build a RC right now but it
>> seems there's a few more jiras[1] that could be quickly resolved.
>>
>> This is why I'm asking all devs to review the jiras that are still
>> opened against 0.90.3 and to either add a fix or punt.
>>
>> Thank you,
>>
>> J-D
>>
>>
>> 1.
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%220.90.3%22+AND+project+%3D+HBASE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
>>
>

There're two actions we need to take:
1. Figure out the root cause for the following test failure:

Running org.apache.hadoop.hbase.
client.TestHCM
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 406.707 sec
<<< FAILURE!

Results :

Tests in error:
 testManyNewConnectionsDoesnotOOME(org.apache.hadoop.hbase.client.TestHCM)
 testRegionCaching(org.apache.hadoop.hbase.client.TestHCM)

2. Backport HBASE-3777 to 0.90

Actually these two actions are related.
I can imagine the disappointment among hbase users if HBASE-3777 weren't
included in 0.90.3

My two cents.

On Tue, May 3, 2011 at 3:01 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]>wrote:

> It's a pretty big change and it would need to be backported, but I
> understand your concern.
>
> In my ideal world, 0.92.0 would be released in not too long and this
> would be a non-issue.
>
> In the real world, for all I know, 0.92.0 could be released in 6
> months or more and people would be struggling with ZK connection
> errors during all that time (and we would tell them to patch their
> 0.90 themselves).
>
> Here's what I propose:
>
>  - Release 0.90.3 without HBASE-3777 since it already has enough going
> and it's almost ready to go out.
>  - Backport HBASE-3777 and post the patch in that jira, considering
> that the 0.90 branch won't be changing a lot in the foreseeable future
> so it should apply cleanly for some time.
>  - Point people to that patch and ask them to try it out on 0.90, I
> know for sure that we'll we doing it here.
>  - In the mean time, the patch will get more usage in trunk as we
> prepare a 0.92 release and might find issues.
>  - Finally consider patching it in for 0.90.4 if we have enough
> confidence in it (with or without some other fixes that we would have
> figured out by then).
>
> Does that sound good to you?
>
> Thx,
>
> J-D
>
> On Tue, May 3, 2011 at 2:20 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > Can we get HBASE-3777 into 0.90.3 ?
> >
> > On Tue, May 3, 2011 at 2:10 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]
> >wrote:
> >
> >> Hi devs,
> >>
> >> I think we should release 0.90.3 pretty soon, it already has 30 fixed
> >> bugs including 4 blockers and a good bunch of nice to have
> >> fixes/improvements.
> >>
> >> Since there are no other blockers we could build a RC right now but it
> >> seems there's a few more jiras[1] that could be quickly resolved.
> >>
> >> This is why I'm asking all devs to review the jiras that are still
> >> opened against 0.90.3 and to either add a fix or punt.
> >>
> >> Thank you,
> >>
> >> J-D
> >>
> >>
> >> 1.
> >>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=fixVersion+%3D+%220.90.3%22+AND+project+%3D+HBASE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC
> >>
> >
>

> Actually these two actions are related.
> I can imagine the disappointment among hbase users if HBASE-3777 weren't
> included in 0.90.3

I can also imagine the disappointment if we release a 0.90.3 that
contains more bugs than it fixes, it goes both ways. Moreover,
HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
don't see how even if someone paid attention to the jira they would
expect to see it in 0.90.3

I'd like to state that I'm not trying to discredit the work that was
done in that Jira, it was a perfect example of open source
collaboration, but I'm rather trying to point out that it's a big
change and that the bigger the change the better the chances are that
there will be bugs lurking in it. You could easily list big patches
that were committed to point releases in the past and I would agree
with you that this is something we've done, but I can also recall a
number of those changes that introduced more bugs and even made some
releases unusable (like 0.20.4). Let's try to learn from our errors.

Finally, even if it's not in 0.90.3, the fact that a backport be made
available means that people can patch it in themselves or that other
distros can decide to include it (like in the next CDH3 update). And
finally we could do a 0.90.4 with it.

J-D

The possibility of HBASE-3777 creating bigger trouble than without is low,
in my opinion.
Maybe we should conduct a poll in user mailing list and count the votes.

On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]>wrote:

> > Actually these two actions are related.
> > I can imagine the disappointment among hbase users if HBASE-3777 weren't
> > included in 0.90.3
>
> I can also imagine the disappointment if we release a 0.90.3 that
> contains more bugs than it fixes, it goes both ways. Moreover,
> HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
> don't see how even if someone paid attention to the jira they would
> expect to see it in 0.90.3
>
> I'd like to state that I'm not trying to discredit the work that was
> done in that Jira, it was a perfect example of open source
> collaboration, but I'm rather trying to point out that it's a big
> change and that the bigger the change the better the chances are that
> there will be bugs lurking in it. You could easily list big patches
> that were committed to point releases in the past and I would agree
> with you that this is something we've done, but I can also recall a
> number of those changes that introduced more bugs and even made some
> releases unusable (like 0.20.4). Let's try to learn from our errors.
>
> Finally, even if it's not in 0.90.3, the fact that a backport be made
> available means that people can patch it in themselves or that other
> distros can decide to include it (like in the next CDH3 update). And
> finally we could do a 0.90.4 with it.
>
> J-D
>

I think changing the connection "identity" handling is a pretty major
change, and I'd be uncomfortable pushing it out in a point release before
it's had time to be adequately tested.  It's not even in the 0.90 branch
yet.  If we're trying to get out a 0.90.3 release sooner than later, then it
doesn't seem to fit the bill.

FYI, I only see one reference to HBASE-3777 on the user list:
http://search-hadoop.com/m/VYHN4QbRQ2

It may be solving real problems that people are having (I hope so!), but I
don't see any clamoring for it to prevent a 0.90.3-rc.

--gh
On Tue, May 3, 2011 at 6:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:

> The possibility of HBASE-3777 creating bigger trouble than without is low,
> in my opinion.
> Maybe we should conduct a poll in user mailing list and count the votes.
>
> On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]
> >wrote:
>
> > > Actually these two actions are related.
> > > I can imagine the disappointment among hbase users if HBASE-3777
> weren't
> > > included in 0.90.3
> >
> > I can also imagine the disappointment if we release a 0.90.3 that
> > contains more bugs than it fixes, it goes both ways. Moreover,
> > HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
> > don't see how even if someone paid attention to the jira they would
> > expect to see it in 0.90.3
> >
> > I'd like to state that I'm not trying to discredit the work that was
> > done in that Jira, it was a perfect example of open source
> > collaboration, but I'm rather trying to point out that it's a big
> > change and that the bigger the change the better the chances are that
> > there will be bugs lurking in it. You could easily list big patches
> > that were committed to point releases in the past and I would agree
> > with you that this is something we've done, but I can also recall a
> > number of those changes that introduced more bugs and even made some
> > releases unusable (like 0.20.4). Let's try to learn from our errors.
> >
> > Finally, even if it's not in 0.90.3, the fact that a backport be made
> > available means that people can patch it in themselves or that other
> > distros can decide to include it (like in the next CDH3 update). And
> > finally we could do a 0.90.4 with it.
> >
> > J-D
> >
>

Can we get hbase-3821 into 0.90.3?
It's a major bug, and a few change can fix it.

Zhou Shuaifeng(Frank)

See email thread 'zk connection leak with TableInput/OutputFormat (CDH3b4,
0.90.1)' which ended up with
https://issues.apache.org/jira/browse/HBASE-3792

See also M.C. Srivas's comment in HBASE-3777:
'We share the same goal: with this patch, we hope to be able to scale YCSB
to 50 client machines, with 500 threads per client, and see how HBase holds
up.'

I still think it is a advisable to integrate HBASE-3777 considering the
current status of TableInputFormat and TableOutputFormat

On Tue, May 3, 2011 at 6:14 PM, Gary Helmling <[EMAIL PROTECTED]> wrote:

> I think changing the connection "identity" handling is a pretty major
> change, and I'd be uncomfortable pushing it out in a point release before
> it's had time to be adequately tested.  It's not even in the 0.90 branch
> yet.  If we're trying to get out a 0.90.3 release sooner than later, then
> it
> doesn't seem to fit the bill.
>
> FYI, I only see one reference to HBASE-3777 on the user list:
> http://search-hadoop.com/m/VYHN4QbRQ2
>
> It may be solving real problems that people are having (I hope so!), but I
> don't see any clamoring for it to prevent a 0.90.3-rc.
>
> --gh
>
>
> On Tue, May 3, 2011 at 6:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
> > The possibility of HBASE-3777 creating bigger trouble than without is
> low,
> > in my opinion.
> > Maybe we should conduct a poll in user mailing list and count the votes.
> >
> > On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]
> > >wrote:
> >
> > > > Actually these two actions are related.
> > > > I can imagine the disappointment among hbase users if HBASE-3777
> > weren't
> > > > included in 0.90.3
> > >
> > > I can also imagine the disappointment if we release a 0.90.3 that
> > > contains more bugs than it fixes, it goes both ways. Moreover,
> > > HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
> > > don't see how even if someone paid attention to the jira they would
> > > expect to see it in 0.90.3
> > >
> > > I'd like to state that I'm not trying to discredit the work that was
> > > done in that Jira, it was a perfect example of open source
> > > collaboration, but I'm rather trying to point out that it's a big
> > > change and that the bigger the change the better the chances are that
> > > there will be bugs lurking in it. You could easily list big patches
> > > that were committed to point releases in the past and I would agree
> > > with you that this is something we've done, but I can also recall a
> > > number of those changes that introduced more bugs and even made some
> > > releases unusable (like 0.20.4). Let's try to learn from our errors.
> > >
> > > Finally, even if it's not in 0.90.3, the fact that a backport be made
> > > available means that people can patch it in themselves or that other
> > > distros can decide to include it (like in the next CDH3 update). And
> > > finally we could do a 0.90.4 with it.
> > >
> > > J-D
> > >
> >
>

Although projects can call a user vote and consider it, project committers make such decisions. Ultimately committers are responsible for insuring the quality of the code base. If a destabilizing change goes in to a point release and users are affected, committers in effect did not do their jobs well enough.

We had considerable trouble around 0.20.4 in this regard, though the change was a LOT bigger and more invasive -- IndexedTable.

Personally, I'm satisfied that HBASE-3777 went into trunk.

   - Andy

> On Tue, May 3, 2011 at 6:00 PM, Ted Yu <[EMAIL PROTECTED]>
> wrote:
>
> > The possibility of HBASE-3777 creating bigger trouble
> > than without is low, in my opinion.
> > Maybe we should conduct a poll in user mailing list
> > and count the votes.

On Tue, May 3, 2011 at 6:31 PM, Zhoushuaifeng <[EMAIL PROTECTED]> wrote:
> Can we get hbase-3821 into 0.90.3?
> It's a major bug, and a few change can fix it.
>
> Zhou Shuaifeng(Frank)
>

Committed.
St.Ack

IMO, HBASE-3777 is a critical fix -- it even addresses a regression
introduced in 0.90.0 -- but its too risky putting it out now in a
release from branch, at least just yet.  It was only committed a day
or so ago (Thanks Karthick and Ted for the hard work getting it in).
I think it needs a bit of bake-in.  We should be rolling a 0.92.0RC
pretty soon.  It'll get some testing then.

We can not risk a point release that is less stable than previous
versions; if we err, the cost in terms of support and community trust
is just too high.

Meantime, any chance of a backport of hbase-3777 Ted?

Good stuff,
St.Ack
On Tue, May 3, 2011 at 6:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> The possibility of HBASE-3777 creating bigger trouble than without is low,
> in my opinion.
> Maybe we should conduct a poll in user mailing list and count the votes.
>
> On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]>wrote:
>
>> > Actually these two actions are related.
>> > I can imagine the disappointment among hbase users if HBASE-3777 weren't
>> > included in 0.90.3
>>
>> I can also imagine the disappointment if we release a 0.90.3 that
>> contains more bugs than it fixes, it goes both ways. Moreover,
>> HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
>> don't see how even if someone paid attention to the jira they would
>> expect to see it in 0.90.3
>>
>> I'd like to state that I'm not trying to discredit the work that was
>> done in that Jira, it was a perfect example of open source
>> collaboration, but I'm rather trying to point out that it's a big
>> change and that the bigger the change the better the chances are that
>> there will be bugs lurking in it. You could easily list big patches
>> that were committed to point releases in the past and I would agree
>> with you that this is something we've done, but I can also recall a
>> number of those changes that introduced more bugs and even made some
>> releases unusable (like 0.20.4). Let's try to learn from our errors.
>>
>> Finally, even if it's not in 0.90.3, the fact that a backport be made
>> available means that people can patch it in themselves or that other
>> distros can decide to include it (like in the next CDH3 update). And
>> finally we could do a 0.90.4 with it.
>>
>> J-D
>>
>

After discussion below, I wonder if 0.92.0RC would come out before 0.90.4
I hope that's the case - we're looking forward to coprocessor which wouldn't
be in 0.90.x anyway.

Regards

On Tue, May 3, 2011 at 9:07 PM, Stack <[EMAIL PROTECTED]> wrote:

> IMO, HBASE-3777 is a critical fix -- it even addresses a regression
> introduced in 0.90.0 -- but its too risky putting it out now in a
> release from branch, at least just yet.  It was only committed a day
> or so ago (Thanks Karthick and Ted for the hard work getting it in).
> I think it needs a bit of bake-in.  We should be rolling a 0.92.0RC
> pretty soon.  It'll get some testing then.
>
> We can not risk a point release that is less stable than previous
> versions; if we err, the cost in terms of support and community trust
> is just too high.
>
> Meantime, any chance of a backport of hbase-3777 Ted?
>
> Good stuff,
> St.Ack
>
>
> On Tue, May 3, 2011 at 6:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > The possibility of HBASE-3777 creating bigger trouble than without is
> low,
> > in my opinion.
> > Maybe we should conduct a poll in user mailing list and count the votes.
> >
> > On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]
> >wrote:
> >
> >> > Actually these two actions are related.
> >> > I can imagine the disappointment among hbase users if HBASE-3777
> weren't
> >> > included in 0.90.3
> >>
> >> I can also imagine the disappointment if we release a 0.90.3 that
> >> contains more bugs than it fixes, it goes both ways. Moreover,
> >> HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
> >> don't see how even if someone paid attention to the jira they would
> >> expect to see it in 0.90.3
> >>
> >> I'd like to state that I'm not trying to discredit the work that was
> >> done in that Jira, it was a perfect example of open source
> >> collaboration, but I'm rather trying to point out that it's a big
> >> change and that the bigger the change the better the chances are that
> >> there will be bugs lurking in it. You could easily list big patches
> >> that were committed to point releases in the past and I would agree
> >> with you that this is something we've done, but I can also recall a
> >> number of those changes that introduced more bugs and even made some
> >> releases unusable (like 0.20.4). Let's try to learn from our errors.
> >>
> >> Finally, even if it's not in 0.90.3, the fact that a backport be made
> >> available means that people can patch it in themselves or that other
> >> distros can decide to include it (like in the next CDH3 update). And
> >> finally we could do a 0.90.4 with it.
> >>
> >> J-D
> >>
> >
>

On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> After discussion below, I wonder if 0.92.0RC would come out before 0.90.4
> I hope that's the case - we're looking forward to coprocessor which wouldn't
> be in 0.90.x anyway.
>

Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
sure when 0.90.4 will see light of day.  There's a good few blockers
and criticals but if a few of us have a go at them, we'll knock it out
tout de suite (This is what I'm working on at mo).

Good stuff,
St.Ack

Maybe we should do an 0.91 dev release tout de suite? Folks who want
3777 and coprocessors and the other nice stuff can then help us bake
towards 92 ?

Todd

On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
> On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> After discussion below, I wonder if 0.92.0RC would come out before 0.90.4
>> I hope that's the case - we're looking forward to coprocessor which wouldn't
>> be in 0.90.x anyway.
>>
>
> Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
> sure when 0.90.4 will see light of day.  There's a good few blockers
> and criticals but if a few of us have a go at them, we'll knock it out
> tout de suite (This is what I'm working on at mo).
>
> Good stuff,
> St.Ack
>

--
Todd Lipcon
Software Engineer, Cloudera

When would 0.91 branch be created ?
We should reduce the number of open critical bugs for 0.90 - each such issue
would soon be integrated to 3 branches after 0.91 branch is created.

On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> Maybe we should do an 0.91 dev release tout de suite? Folks who want
> 3777 and coprocessors and the other nice stuff can then help us bake
> towards 92 ?
>
> Todd
>
> On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
> > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >> After discussion below, I wonder if 0.92.0RC would come out before
> 0.90.4
> >> I hope that's the case - we're looking forward to coprocessor which
> wouldn't
> >> be in 0.90.x anyway.
> >>
> >
> > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
> > sure when 0.90.4 will see light of day.  There's a good few blockers
> > and criticals but if a few of us have a go at them, we'll knock it out
> > tout de suite (This is what I'm working on at mo).
> >
> > Good stuff,
> > St.Ack
> >
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

I was one of those bitten by the connection identity changes in 0.90 and
TableOutputFormat issues.  I was very glad to see HBASE-3777 addressed, and
many thanks to those who did the work to sort it out.  I'd love to have it
soon, but I have to agree that it's a pretty fundamental change and seems
high risk to put into a point release.

I knew there were some big changes moving from 0.20 to 0.90, so I did some
rigorous testing on our cluster (still haven't rolled out 0.90 yet) and
ended up making some non-trivial changes to our HBase usage and automated
tests to accomodate the the connection identity issues in 0.90.  I wouldn't
expect that level of change in a point release, and don't put point releases
through as much testing.

I think it's worth putting more effort into getting 0.92 out the door as
soon as is reasonable to get this change and others out.  Keep the point
releases as risk free as possible.  Users should have a high degree of
confidence that they are strictly improvements, and if their system works on
one point release, it should work on the next without modifications.

Dave

On Tue, May 3, 2011 at 9:07 PM, Stack <[EMAIL PROTECTED]> wrote:

> IMO, HBASE-3777 is a critical fix -- it even addresses a regression
> introduced in 0.90.0 -- but its too risky putting it out now in a
> release from branch, at least just yet.  It was only committed a day
> or so ago (Thanks Karthick and Ted for the hard work getting it in).
> I think it needs a bit of bake-in.  We should be rolling a 0.92.0RC
> pretty soon.  It'll get some testing then.
>
> We can not risk a point release that is less stable than previous
> versions; if we err, the cost in terms of support and community trust
> is just too high.
>
> Meantime, any chance of a backport of hbase-3777 Ted?
>
> Good stuff,
> St.Ack
>
>
> On Tue, May 3, 2011 at 6:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > The possibility of HBASE-3777 creating bigger trouble than without is
> low,
> > in my opinion.
> > Maybe we should conduct a poll in user mailing list and count the votes.
> >
> > On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <[EMAIL PROTECTED]
> >wrote:
> >
> >> > Actually these two actions are related.
> >> > I can imagine the disappointment among hbase users if HBASE-3777
> weren't
> >> > included in 0.90.3
> >>
> >> I can also imagine the disappointment if we release a 0.90.3 that
> >> contains more bugs than it fixes, it goes both ways. Moreover,
> >> HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
> >> don't see how even if someone paid attention to the jira they would
> >> expect to see it in 0.90.3
> >>
> >> I'd like to state that I'm not trying to discredit the work that was
> >> done in that Jira, it was a perfect example of open source
> >> collaboration, but I'm rather trying to point out that it's a big
> >> change and that the bigger the change the better the chances are that
> >> there will be bugs lurking in it. You could easily list big patches
> >> that were committed to point releases in the past and I would agree
> >> with you that this is something we've done, but I can also recall a
> >> number of those changes that introduced more bugs and even made some
> >> releases unusable (like 0.20.4). Let's try to learn from our errors.
> >>
> >> Finally, even if it's not in 0.90.3, the fact that a backport be made
> >> available means that people can patch it in themselves or that other
> >> distros can decide to include it (like in the next CDH3 update). And
> >> finally we could do a 0.90.4 with it.
> >>
> >> J-D
> >>
> >
>

On Wed, May 4, 2011 at 9:10 AM, Dave Latham <[EMAIL PROTECTED]> wrote:

>
> I think it's worth putting more effort into getting 0.92 out the door as
> soon as is reasonable to get this change and others out.  Keep the point
> releases as risk free as possible.  Users should have a high degree of
> confidence that they are strictly improvements, and if their system works
> on
> one point release, it should work on the next without modifications.
>

Absolutely agree. Point releases should change internal implementations, not
interfaces (except for occasionally adding new additional ones).
Implementation changes should be as small/risk free as possible.

-Todd
> On Tue, May 3, 2011 at 9:07 PM, Stack <[EMAIL PROTECTED]> wrote:
>
> > IMO, HBASE-3777 is a critical fix -- it even addresses a regression
> > introduced in 0.90.0 -- but its too risky putting it out now in a
> > release from branch, at least just yet.  It was only committed a day
> > or so ago (Thanks Karthick and Ted for the hard work getting it in).
> > I think it needs a bit of bake-in.  We should be rolling a 0.92.0RC
> > pretty soon.  It'll get some testing then.
> >
> > We can not risk a point release that is less stable than previous
> > versions; if we err, the cost in terms of support and community trust
> > is just too high.
> >
> > Meantime, any chance of a backport of hbase-3777 Ted?
> >
> > Good stuff,
> > St.Ack
> >
> >
> > On Tue, May 3, 2011 at 6:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > > The possibility of HBASE-3777 creating bigger trouble than without is
> > low,
> > > in my opinion.
> > > Maybe we should conduct a poll in user mailing list and count the
> votes.
> > >
> > > On Tue, May 3, 2011 at 5:34 PM, Jean-Daniel Cryans <
> [EMAIL PROTECTED]
> > >wrote:
> > >
> > >> > Actually these two actions are related.
> > >> > I can imagine the disappointment among hbase users if HBASE-3777
> > weren't
> > >> > included in 0.90.3
> > >>
> > >> I can also imagine the disappointment if we release a 0.90.3 that
> > >> contains more bugs than it fixes, it goes both ways. Moreover,
> > >> HBASE-3777 wasn't targeted and still isn't targeted for 0.90.3, so I
> > >> don't see how even if someone paid attention to the jira they would
> > >> expect to see it in 0.90.3
> > >>
> > >> I'd like to state that I'm not trying to discredit the work that was
> > >> done in that Jira, it was a perfect example of open source
> > >> collaboration, but I'm rather trying to point out that it's a big
> > >> change and that the bigger the change the better the chances are that
> > >> there will be bugs lurking in it. You could easily list big patches
> > >> that were committed to point releases in the past and I would agree
> > >> with you that this is something we've done, but I can also recall a
> > >> number of those changes that introduced more bugs and even made some
> > >> releases unusable (like 0.20.4). Let's try to learn from our errors.
> > >>
> > >> Finally, even if it's not in 0.90.3, the fact that a backport be made
> > >> available means that people can patch it in themselves or that other
> > >> distros can decide to include it (like in the next CDH3 update). And
> > >> finally we could do a 0.90.4 with it.
> > >>
> > >> J-D
> > >>
> > >
> >
>

--
Todd Lipcon
Software Engineer, Cloudera

On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:

> When would 0.91 branch be created ?
> We should reduce the number of open critical bugs for 0.90 - each such
> issue
> would soon be integrated to 3 branches after 0.91 branch is created.
>

Sorry, I should have been clear that I would imagine 0.91 would be a "dev
release" series like 0.89. That is to say, there would be no 0.91 branch,
just a few "snapshot style" releases with minimal pre-release testing to get
us in shape for 92. These releases would never have point releases done on
top (and thus not need to have changes backported to them one released).

Consider it another name for an extended release candidate period for 0.92.

-Todd
> On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>
> > Maybe we should do an 0.91 dev release tout de suite? Folks who want
> > 3777 and coprocessors and the other nice stuff can then help us bake
> > towards 92 ?
> >
> > Todd
> >
> > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
> > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > >> After discussion below, I wonder if 0.92.0RC would come out before
> > 0.90.4
> > >> I hope that's the case - we're looking forward to coprocessor which
> > wouldn't
> > >> be in 0.90.x anyway.
> > >>
> > >
> > > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
> > > sure when 0.90.4 will see light of day.  There's a good few blockers
> > > and criticals but if a few of us have a go at them, we'll knock it out
> > > tout de suite (This is what I'm working on at mo).
> > >
> > > Good stuff,
> > > St.Ack
> > >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>

--
Todd Lipcon
Software Engineer, Cloudera

I am looking forward to this 0.91 release.

On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
> > When would 0.91 branch be created ?
> > We should reduce the number of open critical bugs for 0.90 - each such
> > issue
> > would soon be integrated to 3 branches after 0.91 branch is created.
> >
>
> Sorry, I should have been clear that I would imagine 0.91 would be a "dev
> release" series like 0.89. That is to say, there would be no 0.91 branch,
> just a few "snapshot style" releases with minimal pre-release testing to
> get
> us in shape for 92. These releases would never have point releases done on
> top (and thus not need to have changes backported to them one released).
>
> Consider it another name for an extended release candidate period for 0.92.
>
> -Todd
>
>
> > On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> >
> > > Maybe we should do an 0.91 dev release tout de suite? Folks who want
> > > 3777 and coprocessors and the other nice stuff can then help us bake
> > > towards 92 ?
> > >
> > > Todd
> > >
> > > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
> > > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > > >> After discussion below, I wonder if 0.92.0RC would come out before
> > > 0.90.4
> > > >> I hope that's the case - we're looking forward to coprocessor which
> > > wouldn't
> > > >> be in 0.90.x anyway.
> > > >>
> > > >
> > > > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
> > > > sure when 0.90.4 will see light of day.  There's a good few blockers
> > > > and criticals but if a few of us have a go at them, we'll knock it
> out
> > > > tout de suite (This is what I'm working on at mo).
> > > >
> > > > Good stuff,
> > > > St.Ack
> > > >
> > >
> > > --
> > > Todd Lipcon
> > > Software Engineer, Cloudera
> > >
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

Barney Frank's request for help brought me back to this discussion.
When would 0.91 release come ?

On Wed, May 4, 2011 at 10:31 AM, Ted Yu <[EMAIL PROTECTED]> wrote:

> I am looking forward to this 0.91 release.
>
>
> On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>
>> On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>>
>> > When would 0.91 branch be created ?
>> > We should reduce the number of open critical bugs for 0.90 - each such
>> > issue
>> > would soon be integrated to 3 branches after 0.91 branch is created.
>> >
>>
>> Sorry, I should have been clear that I would imagine 0.91 would be a "dev
>> release" series like 0.89. That is to say, there would be no 0.91 branch,
>> just a few "snapshot style" releases with minimal pre-release testing to
>> get
>> us in shape for 92. These releases would never have point releases done on
>> top (and thus not need to have changes backported to them one released).
>>
>> Consider it another name for an extended release candidate period for
>> 0.92.
>>
>> -Todd
>>
>>
>> > On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>> >
>> > > Maybe we should do an 0.91 dev release tout de suite? Folks who want
>> > > 3777 and coprocessors and the other nice stuff can then help us bake
>> > > towards 92 ?
>> > >
>> > > Todd
>> > >
>> > > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
>> > > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> > > >> After discussion below, I wonder if 0.92.0RC would come out before
>> > > 0.90.4
>> > > >> I hope that's the case - we're looking forward to coprocessor which
>> > > wouldn't
>> > > >> be in 0.90.x anyway.
>> > > >>
>> > > >
>> > > > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
>> > > > sure when 0.90.4 will see light of day.  There's a good few blockers
>> > > > and criticals but if a few of us have a go at them, we'll knock it
>> out
>> > > > tout de suite (This is what I'm working on at mo).
>> > > >
>> > > > Good stuff,
>> > > > St.Ack
>> > > >
>> > >
>> > > --
>> > > Todd Lipcon
>> > > Software Engineer, Cloudera
>> > >
>> >
>>
>>
>>
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>>
>
>

We cut cut a 0.91 now as Todd suggests but would need a release
manager to run the release.
St.Ack

On Mon, May 16, 2011 at 9:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> Barney Frank's request for help brought me back to this discussion.
> When would 0.91 release come ?
>
> On Wed, May 4, 2011 at 10:31 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
>> I am looking forward to this 0.91 release.
>>
>>
>> On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>>
>>> On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>>>
>>> > When would 0.91 branch be created ?
>>> > We should reduce the number of open critical bugs for 0.90 - each such
>>> > issue
>>> > would soon be integrated to 3 branches after 0.91 branch is created.
>>> >
>>>
>>> Sorry, I should have been clear that I would imagine 0.91 would be a "dev
>>> release" series like 0.89. That is to say, there would be no 0.91 branch,
>>> just a few "snapshot style" releases with minimal pre-release testing to
>>> get
>>> us in shape for 92. These releases would never have point releases done on
>>> top (and thus not need to have changes backported to them one released).
>>>
>>> Consider it another name for an extended release candidate period for
>>> 0.92.
>>>
>>> -Todd
>>>
>>>
>>> > On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>>> >
>>> > > Maybe we should do an 0.91 dev release tout de suite? Folks who want
>>> > > 3777 and coprocessors and the other nice stuff can then help us bake
>>> > > towards 92 ?
>>> > >
>>> > > Todd
>>> > >
>>> > > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
>>> > > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>>> > > >> After discussion below, I wonder if 0.92.0RC would come out before
>>> > > 0.90.4
>>> > > >> I hope that's the case - we're looking forward to coprocessor which
>>> > > wouldn't
>>> > > >> be in 0.90.x anyway.
>>> > > >>
>>> > > >
>>> > > > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm not
>>> > > > sure when 0.90.4 will see light of day.  There's a good few blockers
>>> > > > and criticals but if a few of us have a go at them, we'll knock it
>>> out
>>> > > > tout de suite (This is what I'm working on at mo).
>>> > > >
>>> > > > Good stuff,
>>> > > > St.Ack
>>> > > >
>>> > >
>>> > > --
>>> > > Todd Lipcon
>>> > > Software Engineer, Cloudera
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Todd Lipcon
>>> Software Engineer, Cloudera
>>>
>>
>>
>

On Mon, May 16, 2011 at 11:00 AM, Stack <[EMAIL PROTECTED]> wrote:

> We cut cut a 0.91 now as Todd suggests but would need a release
> manager to run the release.
>

I would support such a release but unfortunatelty I don't have time to
volunteer to be an RM :(

-Todd
>  On Mon, May 16, 2011 at 9:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > Barney Frank's request for help brought me back to this discussion.
> > When would 0.91 release come ?
> >
> > On Wed, May 4, 2011 at 10:31 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >
> >> I am looking forward to this 0.91 release.
> >>
> >>
> >> On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> >>
> >>> On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >>>
> >>> > When would 0.91 branch be created ?
> >>> > We should reduce the number of open critical bugs for 0.90 - each
> such
> >>> > issue
> >>> > would soon be integrated to 3 branches after 0.91 branch is created.
> >>> >
> >>>
> >>> Sorry, I should have been clear that I would imagine 0.91 would be a
> "dev
> >>> release" series like 0.89. That is to say, there would be no 0.91
> branch,
> >>> just a few "snapshot style" releases with minimal pre-release testing
> to
> >>> get
> >>> us in shape for 92. These releases would never have point releases done
> on
> >>> top (and thus not need to have changes backported to them one
> released).
> >>>
> >>> Consider it another name for an extended release candidate period for
> >>> 0.92.
> >>>
> >>> -Todd
> >>>
> >>>
> >>> > On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]>
> wrote:
> >>> >
> >>> > > Maybe we should do an 0.91 dev release tout de suite? Folks who
> want
> >>> > > 3777 and coprocessors and the other nice stuff can then help us
> bake
> >>> > > towards 92 ?
> >>> > >
> >>> > > Todd
> >>> > >
> >>> > > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
> >>> > > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]>
> wrote:
> >>> > > >> After discussion below, I wonder if 0.92.0RC would come out
> before
> >>> > > 0.90.4
> >>> > > >> I hope that's the case - we're looking forward to coprocessor
> which
> >>> > > wouldn't
> >>> > > >> be in 0.90.x anyway.
> >>> > > >>
> >>> > > >
> >>> > > > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm
> not
> >>> > > > sure when 0.90.4 will see light of day.  There's a good few
> blockers
> >>> > > > and criticals but if a few of us have a go at them, we'll knock
> it
> >>> out
> >>> > > > tout de suite (This is what I'm working on at mo).
> >>> > > >
> >>> > > > Good stuff,
> >>> > > > St.Ack
> >>> > > >
> >>> > >
> >>> > > --
> >>> > > Todd Lipcon
> >>> > > Software Engineer, Cloudera
> >>> > >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Todd Lipcon
> >>> Software Engineer, Cloudera
> >>>
> >>
> >>
> >
>

--
Todd Lipcon
Software Engineer, Cloudera

I assume release manager has to be a committer. So, although I want to help
...

On Mon, May 16, 2011 at 11:00 AM, Stack <[EMAIL PROTECTED]> wrote:

> We cut cut a 0.91 now as Todd suggests but would need a release
> manager to run the release.
> St.Ack
>
> On Mon, May 16, 2011 at 9:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > Barney Frank's request for help brought me back to this discussion.
> > When would 0.91 release come ?
> >
> > On Wed, May 4, 2011 at 10:31 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >
> >> I am looking forward to this 0.91 release.
> >>
> >>
> >> On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> >>
> >>> On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >>>
> >>> > When would 0.91 branch be created ?
> >>> > We should reduce the number of open critical bugs for 0.90 - each
> such
> >>> > issue
> >>> > would soon be integrated to 3 branches after 0.91 branch is created.
> >>> >
> >>>
> >>> Sorry, I should have been clear that I would imagine 0.91 would be a
> "dev
> >>> release" series like 0.89. That is to say, there would be no 0.91
> branch,
> >>> just a few "snapshot style" releases with minimal pre-release testing
> to
> >>> get
> >>> us in shape for 92. These releases would never have point releases done
> on
> >>> top (and thus not need to have changes backported to them one
> released).
> >>>
> >>> Consider it another name for an extended release candidate period for
> >>> 0.92.
> >>>
> >>> -Todd
> >>>
> >>>
> >>> > On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]>
> wrote:
> >>> >
> >>> > > Maybe we should do an 0.91 dev release tout de suite? Folks who
> want
> >>> > > 3777 and coprocessors and the other nice stuff can then help us
> bake
> >>> > > towards 92 ?
> >>> > >
> >>> > > Todd
> >>> > >
> >>> > > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
> >>> > > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]>
> wrote:
> >>> > > >> After discussion below, I wonder if 0.92.0RC would come out
> before
> >>> > > 0.90.4
> >>> > > >> I hope that's the case - we're looking forward to coprocessor
> which
> >>> > > wouldn't
> >>> > > >> be in 0.90.x anyway.
> >>> > > >>
> >>> > > >
> >>> > > > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm
> not
> >>> > > > sure when 0.90.4 will see light of day.  There's a good few
> blockers
> >>> > > > and criticals but if a few of us have a go at them, we'll knock
> it
> >>> out
> >>> > > > tout de suite (This is what I'm working on at mo).
> >>> > > >
> >>> > > > Good stuff,
> >>> > > > St.Ack
> >>> > > >
> >>> > >
> >>> > > --
> >>> > > Todd Lipcon
> >>> > > Software Engineer, Cloudera
> >>> > >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Todd Lipcon
> >>> Software Engineer, Cloudera
> >>>
> >>
> >>
> >
>

Run the unit tests, try it on a handful of machines, basically just
make sure it's usable.

J-D

On Mon, May 16, 2011 at 11:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> I assume release manager has to be a committer. So, although I want to help
> ...
>
> On Mon, May 16, 2011 at 11:00 AM, Stack <[EMAIL PROTECTED]> wrote:
>
>> We cut cut a 0.91 now as Todd suggests but would need a release
>> manager to run the release.
>> St.Ack
>>
>> On Mon, May 16, 2011 at 9:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> > Barney Frank's request for help brought me back to this discussion.
>> > When would 0.91 release come ?
>> >
>> > On Wed, May 4, 2011 at 10:31 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> >
>> >> I am looking forward to this 0.91 release.
>> >>
>> >>
>> >> On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>> >>
>> >>> On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>> > When would 0.91 branch be created ?
>> >>> > We should reduce the number of open critical bugs for 0.90 - each
>> such
>> >>> > issue
>> >>> > would soon be integrated to 3 branches after 0.91 branch is created.
>> >>> >
>> >>>
>> >>> Sorry, I should have been clear that I would imagine 0.91 would be a
>> "dev
>> >>> release" series like 0.89. That is to say, there would be no 0.91
>> branch,
>> >>> just a few "snapshot style" releases with minimal pre-release testing
>> to
>> >>> get
>> >>> us in shape for 92. These releases would never have point releases done
>> on
>> >>> top (and thus not need to have changes backported to them one
>> released).
>> >>>
>> >>> Consider it another name for an extended release candidate period for
>> >>> 0.92.
>> >>>
>> >>> -Todd
>> >>>
>> >>>
>> >>> > On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]>
>> wrote:
>> >>> >
>> >>> > > Maybe we should do an 0.91 dev release tout de suite? Folks who
>> want
>> >>> > > 3777 and coprocessors and the other nice stuff can then help us
>> bake
>> >>> > > towards 92 ?
>> >>> > >
>> >>> > > Todd
>> >>> > >
>> >>> > > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
>> >>> > > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]>
>> wrote:
>> >>> > > >> After discussion below, I wonder if 0.92.0RC would come out
>> before
>> >>> > > 0.90.4
>> >>> > > >> I hope that's the case - we're looking forward to coprocessor
>> which
>> >>> > > wouldn't
>> >>> > > >> be in 0.90.x anyway.
>> >>> > > >>
>> >>> > > >
>> >>> > > > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm
>> not
>> >>> > > > sure when 0.90.4 will see light of day.  There's a good few
>> blockers
>> >>> > > > and criticals but if a few of us have a go at them, we'll knock
>> it
>> >>> out
>> >>> > > > tout de suite (This is what I'm working on at mo).
>> >>> > > >
>> >>> > > > Good stuff,
>> >>> > > > St.Ack
>> >>> > > >
>> >>> > >
>> >>> > > --
>> >>> > > Todd Lipcon
>> >>> > > Software Engineer, Cloudera
>> >>> > >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Todd Lipcon
>> >>> Software Engineer, Cloudera
>> >>>
>> >>
>> >>
>> >
>>
>

On Mon, May 16, 2011 at 11:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> I assume release manager has to be a committer. So, although I want to help
> ...
>

Yes, or at least needs a committer to ride shotgun to do the posting
of the release and the few tagging commits needed.
St.Ack

I can do some test for 0.90.X if it needs.
-----邮件原件-----
发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 代表 Jean-Daniel Cryans
发送时间: 2011年5月17日 2:31
收件人: [EMAIL PROTECTED]
主题: Re: Release 0.90.3 soon?

Run the unit tests, try it on a handful of machines, basically just
make sure it's usable.

J-D

On Mon, May 16, 2011 at 11:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> I assume release manager has to be a committer. So, although I want to help
> ...
>
> On Mon, May 16, 2011 at 11:00 AM, Stack <[EMAIL PROTECTED]> wrote:
>
>> We cut cut a 0.91 now as Todd suggests but would need a release
>> manager to run the release.
>> St.Ack
>>
>> On Mon, May 16, 2011 at 9:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> > Barney Frank's request for help brought me back to this discussion.
>> > When would 0.91 release come ?
>> >
>> > On Wed, May 4, 2011 at 10:31 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> >
>> >> I am looking forward to this 0.91 release.
>> >>
>> >>
>> >> On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
>> >>
>> >>> On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>> > When would 0.91 branch be created ?
>> >>> > We should reduce the number of open critical bugs for 0.90 - each
>> such
>> >>> > issue
>> >>> > would soon be integrated to 3 branches after 0.91 branch is created.
>> >>> >
>> >>>
>> >>> Sorry, I should have been clear that I would imagine 0.91 would be a
>> "dev
>> >>> release" series like 0.89. That is to say, there would be no 0.91
>> branch,
>> >>> just a few "snapshot style" releases with minimal pre-release testing
>> to
>> >>> get
>> >>> us in shape for 92. These releases would never have point releases done
>> on
>> >>> top (and thus not need to have changes backported to them one
>> released).
>> >>>
>> >>> Consider it another name for an extended release candidate period for
>> >>> 0.92.
>> >>>
>> >>> -Todd
>> >>>
>> >>>
>> >>> > On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]>
>> wrote:
>> >>> >
>> >>> > > Maybe we should do an 0.91 dev release tout de suite? Folks who
>> want
>> >>> > > 3777 and coprocessors and the other nice stuff can then help us
>> bake
>> >>> > > towards 92 ?
>> >>> > >
>> >>> > > Todd
>> >>> > >
>> >>> > > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
>> >>> > > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]>
>> wrote:
>> >>> > > >> After discussion below, I wonder if 0.92.0RC would come out
>> before
>> >>> > > 0.90.4
>> >>> > > >> I hope that's the case - we're looking forward to coprocessor
>> which
>> >>> > > wouldn't
>> >>> > > >> be in 0.90.x anyway.
>> >>> > > >>
>> >>> > > >
>> >>> > > > Plan is to put up a 0.92.0 'soon', in the next week or so.  I'm
>> not
>> >>> > > > sure when 0.90.4 will see light of day.  There's a good few
>> blockers
>> >>> > > > and criticals but if a few of us have a go at them, we'll knock
>> it
>> >>> out
>> >>> > > > tout de suite (This is what I'm working on at mo).
>> >>> > > >
>> >>> > > > Good stuff,
>> >>> > > > St.Ack
>> >>> > > >
>> >>> > >
>> >>> > > --
>> >>> > > Todd Lipcon
>> >>> > > Software Engineer, Cloudera
>> >>> > >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Todd Lipcon
>> >>> Software Engineer, Cloudera
>> >>>
>> >>
>> >>
>> >
>>
>

We were discussing release of 0.91 off of trunk.

On Mon, May 16, 2011 at 6:16 PM, Gaojinchao <[EMAIL PROTECTED]> wrote:

> I can do some test for 0.90.X if it needs.
>
>
> -----邮件原件-----
> 发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 代表 Jean-Daniel Cryans
> 发送时间: 2011年5月17日 2:31
> 收件人: [EMAIL PROTECTED]
> 主题: Re: Release 0.90.3 soon?
>
> Run the unit tests, try it on a handful of machines, basically just
> make sure it's usable.
>
> J-D
>
> On Mon, May 16, 2011 at 11:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > I assume release manager has to be a committer. So, although I want to
> help
> > ...
> >
> > On Mon, May 16, 2011 at 11:00 AM, Stack <[EMAIL PROTECTED]> wrote:
> >
> >> We cut cut a 0.91 now as Todd suggests but would need a release
> >> manager to run the release.
> >> St.Ack
> >>
> >> On Mon, May 16, 2011 at 9:26 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >> > Barney Frank's request for help brought me back to this discussion.
> >> > When would 0.91 release come ?
> >> >
> >> > On Wed, May 4, 2011 at 10:31 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >> >
> >> >> I am looking forward to this 0.91 release.
> >> >>
> >> >>
> >> >> On Wed, May 4, 2011 at 10:23 AM, Todd Lipcon <[EMAIL PROTECTED]>
> wrote:
> >> >>
> >> >>> On Wed, May 4, 2011 at 8:57 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >> >>>
> >> >>> > When would 0.91 branch be created ?
> >> >>> > We should reduce the number of open critical bugs for 0.90 - each
> >> such
> >> >>> > issue
> >> >>> > would soon be integrated to 3 branches after 0.91 branch is
> created.
> >> >>> >
> >> >>>
> >> >>> Sorry, I should have been clear that I would imagine 0.91 would be a
> >> "dev
> >> >>> release" series like 0.89. That is to say, there would be no 0.91
> >> branch,
> >> >>> just a few "snapshot style" releases with minimal pre-release
> testing
> >> to
> >> >>> get
> >> >>> us in shape for 92. These releases would never have point releases
> done
> >> on
> >> >>> top (and thus not need to have changes backported to them one
> >> released).
> >> >>>
> >> >>> Consider it another name for an extended release candidate period
> for
> >> >>> 0.92.
> >> >>>
> >> >>> -Todd
> >> >>>
> >> >>>
> >> >>> > On Tue, May 3, 2011 at 10:47 PM, Todd Lipcon <[EMAIL PROTECTED]>
> >> wrote:
> >> >>> >
> >> >>> > > Maybe we should do an 0.91 dev release tout de suite? Folks who
> >> want
> >> >>> > > 3777 and coprocessors and the other nice stuff can then help us
> >> bake
> >> >>> > > towards 92 ?
> >> >>> > >
> >> >>> > > Todd
> >> >>> > >
> >> >>> > > On Tuesday, May 3, 2011, Stack <[EMAIL PROTECTED]> wrote:
> >> >>> > > > On Tue, May 3, 2011 at 9:21 PM, Ted Yu <[EMAIL PROTECTED]>
> >> wrote:
> >> >>> > > >> After discussion below, I wonder if 0.92.0RC would come out
> >> before
> >> >>> > > 0.90.4
> >> >>> > > >> I hope that's the case - we're looking forward to coprocessor
> >> which
> >> >>> > > wouldn't
> >> >>> > > >> be in 0.90.x anyway.
> >> >>> > > >>
> >> >>> > > >
> >> >>> > > > Plan is to put up a 0.92.0 'soon', in the next week or so.
>  I'm
> >> not
> >> >>> > > > sure when 0.90.4 will see light of day.  There's a good few
> >> blockers
> >> >>> > > > and criticals but if a few of us have a go at them, we'll
> knock
> >> it
> >> >>> out
> >> >>> > > > tout de suite (This is what I'm working on at mo).
> >> >>> > > >
> >> >>> > > > Good stuff,
> >> >>> > > > St.Ack
> >> >>> > > >
> >> >>> > >
> >> >>> > > --
> >> >>> > > Todd Lipcon
> >> >>> > > Software Engineer, Cloudera
> >> >>> > >
> >> >>> >
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Todd Lipcon
> >> >>> Software Engineer, Cloudera
> >> >>>
> >> >>
> >> >>
> >> >
> >>
> >
>