Hi folks,

I would like to open a discussion on how we can make HBase work well with a
supported/released version of Hadoop. HBase currently ships with a hadoop
jar and that hadoop jar is from hadoop 0.20 + a set of ten/twenty patches.
Most of these patches are focussed on HDFS append support in hadoop 0.20.
These cannot be ported back to the 0.20 branch without affecting stability
of the hadoop 0.20 branch. On the other hand, it is premature for hbase
deployments to use hadoop 0.21 because hadoop 0.21 is still under testing
and will take some time to stabilize.

My proposal is to create a new branch off the hadoop 0.20 branch and name
it branch-0.20-hbase. It will have support for append/sync and will be API
compatible with the hadoop 0.20 branch. However, this branch will be marked
"experimental" and API compatibility is subject to change. This branch will
contain all of hdfs/mapreduce/core.

If the community likes this idea, I will volunteer myself to be the release
manager for this new branch and will propose a formal vote.

comments/feedback/questions are most welcome.
dhruba
--
Connect to me at http://www.facebook.com/dhruba

I have a few questions about this proposal:

1) Will we open new JIRAs separately for each change we want to commit, and
go through the normal review process? Currently the 20-append work has been
mostly going on under HDFS-142 for whatever reason, with ancillary issues
only for bugs that also exist in trunk.
2) Do we plan to do a release off the branch, or is it meant only as a
repository for sharing patches and a tree?
3) If we do a release, what version number would we give it and how would it
be presented on the download/release pages?

I'm certainly not against the idea, just would like to open discussion on
the above points. The other alternative as I see it is to have those working
on this branch do so somewhere like github - the advantages to that would be
(a) it provides a more open way for non-committers to contribute, which is
important since we're working closely with the HBase team on this, and (b)
it doesn't add confusion to the main Hadoop jira and download pages. The
disadvantage of course is that it fragments the code repository and we can't
really do a release as easily.

Thanks
-Todd

On Fri, May 7, 2010 at 10:34 AM, Dhruba Borthakur <[EMAIL PROTECTED]> wrote:

> Hi folks,
>
> I would like to open a discussion on how we can make HBase work well with a
> supported/released version of Hadoop. HBase currently ships with a hadoop
> jar and that hadoop jar is from hadoop 0.20 + a set of ten/twenty patches.
> Most of these patches are focussed on HDFS append support in hadoop 0.20.
> These cannot be ported back to the 0.20 branch without affecting stability
> of the hadoop 0.20 branch. On the other hand, it is premature for hbase
> deployments to use hadoop 0.21 because hadoop 0.21 is still under testing
> and will take some time to stabilize.
>
> My proposal is to create a new branch off the hadoop 0.20 branch and name
> it branch-0.20-hbase. It will have support for append/sync and will be API
> compatible with the hadoop 0.20 branch. However, this branch will be marked
> "experimental" and API compatibility is subject to change. This branch will
> contain all of hdfs/mapreduce/core.
>
> If the community likes this idea, I will volunteer myself to be the release
> manager for this new branch and will propose a formal vote.
>
> comments/feedback/questions are most welcome.
> dhruba
>
>
> --
> Connect to me at http://www.facebook.com/dhruba
>

--
Todd Lipcon
Software Engineer, Cloudera

On 05/07/2010 10:57 AM, Todd Lipcon wrote:
> 1) Will we open new JIRAs separately for each change we want to commit, and
> go through the normal review process? Currently the 20-append work has been
> mostly going on under HDFS-142 for whatever reason, with ancillary issues
> only for bugs that also exist in trunk.

I think the proposal discussed yesterday was that the release manager
has the power to determine which patches are merged from trunk to his
branch, to cherry pick.  But for patches that are never committed to
trunk but only to his branch, I think we should use normal rules.  Note
that, under normal rules, the release manager still has veto power over
his branch.

> The other alternative as I see it is to have those working
> on this branch do so somewhere like github - the advantages to that would be
> (a) it provides a more open way for non-committers to contribute, which is
> important since we're working closely with the HBase team on this, and (b)
> it doesn't add confusion to the main Hadoop jira and download pages. The
> disadvantage of course is that it fragments the code repository and we can't
> really do a release as easily.

If the purpose of the branch is for diverse Apache contributors to share
code and make Apache releases, we should keep it at Apache rather than
at github.

If the branch really is only intended to be used by HBase, then perhaps
the branch could live under hbase, e.g., hbase/branches/hdfs-0.20

If we think it might be used by others beyond HBase, or by clusters that
are used for more than just HBase, then we might keep it under HDFS.  We
could label it according to the feature it concerns, e.g.,
hdfs/branches/0.20-append, or, if we think it's a set of features of
which HBase is the only consumer, then hdfs/branches/0.20-hbase might
make sense.

Another alternative might be to name the branch after the release
manager.  So this could be named hdfs/branches/0.20-dhruba.  Then, when
it comes time to make a release from this branch, we might name the
release something different, like or 0.20.3 or somesuch.

This has the potential to create a lot of fragmentation.  Ultimately we
depend on the PMC to control this by not voting for releases from a
multitude of branches.  But, prior to that, we might discourage folks
from creating such branches if we think they'll unduly fragment things.

The current proposal is to fragment 0.20 into two variants, hbase and
vanilla.  It's probable that someone might also propose a secure
fragment.  Three variants might be confusing.  Is there any chance we
could combine some of these?  For example, could vanilla become secure,
or could hbase become secure?  Do folks think three fragments would be
acceptable?  If not, which would you drop or merge?

We can delay final answers to such questions until a release vote, but
it'd be good to have at least a general direction earlier.

Doug

I'm a little confused and concerned now that I learn that hbase uses a patches
hadoop. For Debian I use plain hadoop under hbase and it seems to work in
testing environments.

- Are these patches necessary to run HBase?
- Where can I find these patches?
- Why aren't these patches included in hadoop? Are they too unstable?
- If they're unstable, does this mean, HBase is unstable?

Should I worry at all about these patches for the Debian packages?

regards,

Thomas Koch, http://www.koch.ro

On Sat, May 8, 2010 at 9:59 AM, Thomas Koch <[EMAIL PROTECTED]> wrote:

> I'm a little confused and concerned now that I learn that hbase uses a
> patches
> hadoop. For Debian I use plain hadoop under hbase and it seems to work in
> testing environments.
> - Are these patches necessary to run HBase?
>

It will work unless you have failures, in which case it will lose edits.
HBase relies on the "hflush" API (called "sync" in 0.20) which does not work
properly in 0.20 without significant patching.

Without this patch series, HBase will certainly run, but I could never
recommend running it in a production environment where data loss is a
show-stopper.
> - Where can I find these patches?
>

Currently they're in various places on the JIRA - HDFS-200, HDFS-142,
HDFS-826, HDFS-561, etc. I have a github branch up which contains them all
applied, but I haven't tested it beyond unit tests - my testing is all
happening in our CDH3 tree, and afaik Dhruba's testing is on their FB
internal tree.

> - Why aren't these patches included in hadoop? Are they too unstable?
>

Yes, the policy is not to make such significant changes in patch releases,
so they would need to be voted into the 0.20 series. It's not that they're
entirely unstable, it's just that the code is very tricky and still under
development. The upcoming 0.21 release has a *different* implementation of
Append which also hasn't been tested significantly in real life failure
scenarios, but it's important that we keep the stable release stable.
> - If they're unstable, does this mean, HBase is unstable?
>
>
Again I would not say it's terribly unstable - but it's nowhere near the
level of stability that Hadoop is

>  Should I worry at all about these patches for the Debian packages?

If you expect that people might actually want to run a production HBase,
they should have the patches. If you expect people to just be playing around
on single node "clusters" where failures aren't an issue, best to skip. Of
course, even for production usage, I wouldn't recommend running what we've
got now - wait a month or two and it should be one more notch up the
stability/testing scale.

-Todd

--
Todd Lipcon
Software Engineer, Cloudera

On Fri, May 7, 2010 at 10:34 AM, Dhruba Borthakur <[EMAIL PROTECTED]> wrote:
> My proposal is to create a new branch off the hadoop 0.20 branch and name
> it branch-0.20-hbase. It will have support for append/sync and will be API
> compatible with the hadoop 0.20 branch. However, this branch will be marked
> "experimental" and API compatibility is subject to change. This branch will
> contain all of hdfs/mapreduce/core.
>
> If the community likes this idea...
>
I like this idea.  It can be a little tough keeping up with latest
state of the 0.20 "append" patch set.  Having the set all applied in
the one well-known place will make collaboration and discussion of the
current state of 0.20 "append" the easier.

Would hbase be the only party interested in such a branch?  (Scribe?)

St.Ack

On Fri, May 7, 2010 at 10:34 AM, Dhruba Borthakur <[EMAIL PROTECTED]> wrote:
>This branch will contain all of hdfs/mapreduce/core.
>
Should it be all of hadoop?  Could it be hdfs only?
St.Ack

On Sun, May 9, 2010 at 3:15 PM, Stack <[EMAIL PROTECTED]> wrote:
> Should it be all of hadoop?  Could it be hdfs only?
>

Please ignore the above question (I just took a look at 0.20 repo).
St.Ack

I will try to explain my opinion on some of the questions being raised so
far. Of course all these are open for discussion and nothing is final at
this moment.

1. This code base is primarily targeted for usage by HBase and Scribe. Both
of these are Apache open source projects.
2. Accordingly, my proposal is to name the branch hadoop-0.20-append. This
name is more generic than the earlier one I suggested.
3. The proposal to pull patches into this branch will follow normal
conventions that we follow in Hadoop. However, the release manager would
have an option to veto a patch from being pulled into the branch.
4. if this type of branching causes too many forks of core Hadoop, then we
can aim to merge some of them after some time. The time duration depends on
the stability of the code in that particular branch and is difficult to
predict. The PMC, of course, has to approve of any new branch; so, in effect
can prevent undesired multiple forks if that becomes a problem in the
future.
5. code changes to this new branch will go through the normal process via
JIRAs, code reviews, unit tests, etc.
6. the goal is to have a standard hadoop release from  this branch at some
future point. if course, such a release has to be approved by the PMC. The
release could be marked as "experimental" or some such thing if deemed
appropriate by the PMC.

thanks,
dhruba
On Sun, May 9, 2010 at 3:26 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Sun, May 9, 2010 at 3:15 PM, Stack <[EMAIL PROTECTED]> wrote:
> > Should it be all of hadoop?  Could it be hdfs only?
> >
>
> Please ignore the above question (I just took a look at 0.20 repo).
> St.Ack
>

--
Connect to me at http://www.facebook.com/dhruba

+1 on the below.
St.Ack

On Sun, May 9, 2010 at 9:50 PM, Dhruba Borthakur <[EMAIL PROTECTED]> wrote:
> I will try to explain my opinion on some of the questions being raised so
> far. Of course all these are open for discussion and nothing is final at
> this moment.
>
> 1. This code base is primarily targeted for usage by HBase and Scribe. Both
> of these are Apache open source projects.
> 2. Accordingly, my proposal is to name the branch hadoop-0.20-append. This
> name is more generic than the earlier one I suggested.
> 3. The proposal to pull patches into this branch will follow normal
> conventions that we follow in Hadoop. However, the release manager would
> have an option to veto a patch from being pulled into the branch.
> 4. if this type of branching causes too many forks of core Hadoop, then we
> can aim to merge some of them after some time. The time duration depends on
> the stability of the code in that particular branch and is difficult to
> predict. The PMC, of course, has to approve of any new branch; so, in effect
> can prevent undesired multiple forks if that becomes a problem in the
> future.
> 5. code changes to this new branch will go through the normal process via
> JIRAs, code reviews, unit tests, etc.
> 6. the goal is to have a standard hadoop release from  this branch at some
> future point. if course, such a release has to be approved by the PMC. The
> release could be marked as "experimental" or some such thing if deemed
> appropriate by the PMC.
>
> thanks,
> dhruba
>
>
> On Sun, May 9, 2010 at 3:26 PM, Stack <[EMAIL PROTECTED]> wrote:
>
>> On Sun, May 9, 2010 at 3:15 PM, Stack <[EMAIL PROTECTED]> wrote:
>> > Should it be all of hadoop?  Could it be hdfs only?
>> >
>>
>> Please ignore the above question (I just took a look at 0.20 repo).
>> St.Ack
>>
>
>
>
> --
> Connect to me at http://www.facebook.com/dhruba
>

Let me understand this:

a) the hbase folks have been required to patch hadoop due to bugs
b) they have been doing this for X months now
c) we finally have momentum on getting 0.21 out the door
d) hey, let's make their life easier and take resources out of 0.21 by creating a branch

Are we willing to create a branch for everyone that asks? What happens if mahout/lucene/solr/joes-random-application asks?  Is it a good idea to create a branch that hopefully has a very short life time?   Is it the latest fashion amongst the PMC to request random branches?  

trunk
0.21
0.20
0.20-append
0.20-security-sure-hope-this-turns-into-1.0
0.20-lifecycle-management-stuff-that-seems-to-never-get-committed
...

I'm not PMC, but can I make requests too, since I have to patch what we use?

0.20-capacity-scheduler-is-broken-but-we-shipped-it-anyway
0.20-stop-using-bsd-and-gnu-only-extensions-during-forks
0.20-hadoop-devs-cant-spell

I'd rather have the HBase folks put pressure on the Hadoop PMC to get 0.21 out the door than create a custom-to-be-thrown-away-in-less-than-a-year branch.  This way we *all* benefit rather than a select, but vocal group.

On Mon, May 10, 2010 at 9:58 AM, Allen Wittenauer
<[EMAIL PROTECTED]> wrote:
>
> Let me understand this:
>
> a) the hbase folks have been required to patch hadoop due to bugs

The branch is to work on adding a feature to 0.20, not for fixing bugs.

> c) we finally have momentum on getting 0.21 out the door
> d) hey, let's make their life easier and take resources out of 0.21 by creating a branch
>

The above is a fallacious setup.  How does a branch in 0.20 detract
from the 0.21 momentum (The append feature that we'd work on in 0.20
branch has little relation to how append works in 0.21).
> Are we willing to create a branch for everyone that asks? What happens if mahout/lucene/solr/joes-random-application asks?  Is it a good idea to create a branch that hopefully has a very short life time?   Is it the latest fashion amongst the PMC to request random branches?
>
> trunk
> 0.21
> 0.20
> 0.20-append
> 0.20-security-sure-hope-this-turns-into-1.0
> 0.20-lifecycle-management-stuff-that-seems-to-never-get-committed
> ...
>
> I'm not PMC, but can I make requests too, since I have to patch what we use?
>

Of course you can.

> I'd rather have the HBase folks put pressure on the Hadoop PMC to get 0.21 out the door than create a custom-to-be-thrown-away-in-less-than-a-year branch.  This way we *all* benefit rather than a select, but vocal group.

We're all behind 0.21.  Its the future.

St.Ack

On May 10, 2010, at 10:18 AM, Stack wrote:
> The above is a fallacious setup.  How does a branch in 0.20 detract
> from the 0.21 momentum (The append feature that we'd work on in 0.20
> branch has little relation to how append works in 0.21).

There are X amount of hours that people can put into Hadoop.  If Y amount goes into 0.20-append, then 0.21 is now left with X-Y.   X-Y < X.

>> I'd rather have the HBase folks put pressure on the Hadoop PMC to get 0.21 out the door than create a custom-to-be-thrown-away-in-less-than-a-year branch.  This way we *all* benefit rather than a select, but vocal group.
>
> We're all behind 0.21.  Its the future.

Great.  Start using the time you'd put into 0.20-append into 0.21 and then we'll all be in a better place.

On Mon, May 10, 2010 at 10:18 AM, Stack <[EMAIL PROTECTED]> wrote:
> On Mon, May 10, 2010 at 9:58 AM, Allen Wittenauer
> <[EMAIL PROTECTED]> wrote:
>>
>> Let me understand this:
>>
>> a) the hbase folks have been required to patch hadoop due to bugs
>
> The branch is to work on adding a feature to 0.20, not for fixing bugs.
>
>> c) we finally have momentum on getting 0.21 out the door
>> d) hey, let's make their life easier and take resources out of 0.21 by creating a branch
>>
>
> The above is a fallacious setup.  How does a branch in 0.20 detract
> from the 0.21 momentum (The append feature that we'd work on in 0.20
> branch has little relation to how append works in 0.21).

For what it's worth, though, the majority of the size of the 0.20
append patch is made up of additional unit tests. I have started
forward-porting these new tests to the trunk append and it's already
exposed a number of bugs. So while it's tempting to say that the 0.20
append is "wasted effort", it really is benefiting the entire
community and the 0.21 release as well.

-Todd

>
>
>> Are we willing to create a branch for everyone that asks? What happens if mahout/lucene/solr/joes-random-application asks?  Is it a good idea to create a branch that hopefully has a very short life time?   Is it the latest fashion amongst the PMC to request random branches?
>>
>> trunk
>> 0.21
>> 0.20
>> 0.20-append
>> 0.20-security-sure-hope-this-turns-into-1.0
>> 0.20-lifecycle-management-stuff-that-seems-to-never-get-committed
>> ...
>>
>> I'm not PMC, but can I make requests too, since I have to patch what we use?
>>
>
> Of course you can.
>
>> I'd rather have the HBase folks put pressure on the Hadoop PMC to get 0.21 out the door than create a custom-to-be-thrown-away-in-less-than-a-year branch.  This way we *all* benefit rather than a select, but vocal group.
>
> We're all behind 0.21.  Its the future.
>
> St.Ack
>

--
Todd Lipcon
Software Engineer, Cloudera

On Mon, May 10, 2010 at 10:24 AM, Allen Wittenauer
<[EMAIL PROTECTED]> wrote:
>
> On May 10, 2010, at 10:18 AM, Stack wrote:
>> The above is a fallacious setup.  How does a branch in 0.20 detract
>> from the 0.21 momentum (The append feature that we'd work on in 0.20
>> branch has little relation to how append works in 0.21).
>
> There are X amount of hours that people can put into Hadoop.  If Y amount goes into 0.20-append, then 0.21 is now left with X-Y.   X-Y < X.
>
>>> I'd rather have the HBase folks put pressure on the Hadoop PMC to get 0.21 out the door than create a custom-to-be-thrown-away-in-less-than-a-year branch.  This way we *all* benefit rather than a select, but vocal group.
>>
>> We're all behind 0.21.  Its the future.
>
> Great.  Start using the time you'd put into 0.20-append into 0.21 and then we'll all be in a better place.

That's not how it works though - people have adopted and use Hadoop
0.20 because of the fact that people like Yahoo, Facebook, etc run it
on multi-thousand node clusters and have done so for months (or soon
to be years now).

On May 10, 2010, at 11:05 AM, Ryan Rawson wrote:
> That's not how it works though - people have adopted and use Hadoop
> 0.20 because of the fact that people like Yahoo, Facebook, etc run it
> on multi-thousand node clusters and have done so for months (or soon
> to be years now).
If you look through Yahoo!'s changelog, it is hard to call that 0.20.

> From: [EMAIL PROTECTED]
> Date: Mon, 10 May 2010 10:45:13 -0700
> Subject: Re: Hadoop support for hbase
> To: [EMAIL PROTECTED]
>

> > The above is a fallacious setup.  How does a branch in 0.20 detract
> > from the 0.21 momentum (The append feature that we'd work on in 0.20
> > branch has little relation to how append works in 0.21).
>
> For what it's worth, though, the majority of the size of the 0.20
> append patch is made up of additional unit tests. I have started
> forward-porting these new tests to the trunk append and it's already
> exposed a number of bugs. So while it's tempting to say that the 0.20
> append is "wasted effort", it really is benefiting the entire
> community and the 0.21 release as well.
>
> -Todd
>

Sometimes you have to slow down to go faster.
     
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2

Given that the 0.20-append branch pretty much already exists
unofficially, via IRC, IM and email forwarded patchsets, it seems like
giving it an official home is just recognizing the status quo.
Especially since 0.21 probably won't be getting rolled out into
production everywhere the first day it's officially released.  If the
work's going on anyways, I don't see how giving people a shared home
hurts matters, if anything it gives them a better shared touchpoint
for forward-porting bugfixes to 0.21.

A case could be made that by making it more painful to run
0.20-append, more momentum is created towards 0.21 but since Tom is
already on top of 21 and seemingly doing an excellent job, and since
the HBase community will probably be some of the first people to move
to 0.21 anyways, I don't see why having 0.20-append will damage 0.21's
momentum at this point.

On Mon, May 10, 2010 at 4:21 PM, Michael Segel
<[EMAIL PROTECTED]> wrote:
>
>
>
>> From: [EMAIL PROTECTED]
>> Date: Mon, 10 May 2010 10:45:13 -0700
>> Subject: Re: Hadoop support for hbase
>> To: [EMAIL PROTECTED]
>>
>
>> > The above is a fallacious setup.  How does a branch in 0.20 detract
>> > from the 0.21 momentum (The append feature that we'd work on in 0.20
>> > branch has little relation to how append works in 0.21).
>>
>> For what it's worth, though, the majority of the size of the 0.20
>> append patch is made up of additional unit tests. I have started
>> forward-porting these new tests to the trunk append and it's already
>> exposed a number of bugs. So while it's tempting to say that the 0.20
>> append is "wasted effort", it really is benefiting the entire
>> community and the 0.21 release as well.
>>
>> -Todd
>>
>
> Sometimes you have to slow down to go faster.
>
>
>
> _________________________________________________________________
> Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2

@Allen: we are definitely behind 0.21 release. Tom White is guiding that
release and most developers are committed to removing blockers for that
release. Todd rightly mentions that the work being done for 0.20 benefits
0.21 as well.

@Jay: Thanks for summing it up so well. I completely agree with your
viewpoint.

thanks
dhruba
On Mon, May 10, 2010 at 2:06 PM, Jay Booth <[EMAIL PROTECTED]> wrote:

> Given that the 0.20-append branch pretty much already exists
> unofficially, via IRC, IM and email forwarded patchsets, it seems like
> giving it an official home is just recognizing the status quo.
> Especially since 0.21 probably won't be getting rolled out into
> production everywhere the first day it's officially released.  If the
> work's going on anyways, I don't see how giving people a shared home
> hurts matters, if anything it gives them a better shared touchpoint
> for forward-porting bugfixes to 0.21.
>
> A case could be made that by making it more painful to run
> 0.20-append, more momentum is created towards 0.21 but since Tom is
> already on top of 21 and seemingly doing an excellent job, and since
> the HBase community will probably be some of the first people to move
> to 0.21 anyways, I don't see why having 0.20-append will damage 0.21's
> momentum at this point.
>
>
>
> On Mon, May 10, 2010 at 4:21 PM, Michael Segel
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >> From: [EMAIL PROTECTED]
> >> Date: Mon, 10 May 2010 10:45:13 -0700
> >> Subject: Re: Hadoop support for hbase
> >> To: [EMAIL PROTECTED]
> >>
> >
> >> > The above is a fallacious setup.  How does a branch in 0.20 detract
> >> > from the 0.21 momentum (The append feature that we'd work on in 0.20
> >> > branch has little relation to how append works in 0.21).
> >>
> >> For what it's worth, though, the majority of the size of the 0.20
> >> append patch is made up of additional unit tests. I have started
> >> forward-porting these new tests to the trunk append and it's already
> >> exposed a number of bugs. So while it's tempting to say that the 0.20
> >> append is "wasted effort", it really is benefiting the entire
> >> community and the 0.21 release as well.
> >>
> >> -Todd
> >>
> >
> > Sometimes you have to slow down to go faster.
> >
> >
> >
> > _________________________________________________________________
> > Hotmail is redefining busy with tools for the New Busy. Get more from
> your inbox.
> >
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
>

--
Connect to me at http://www.facebook.com/dhruba

Hello folks,

I created a branch for doing the append/sync support for Hadoop 0.20. You
can fetch the branch via

http://svn.apache.org/repos/asf/hadoop/common/branches/branch-0.20-append/

If you feel that there are some JIRAS that need to go into this branch,
please update the fix-version of those JIRAS with the tag
"0.20-append</jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310942&fixfor=12315103>
".

thanks,
dhruba

On Mon, May 10, 2010 at 11:35 PM, Dhruba Borthakur <[EMAIL PROTECTED]> wrote:
> @Allen: we are definitely behind 0.21 release. Tom White is guiding that
> release and most developers are committed to removing blockers for that
> release. Todd rightly mentions that the work being done for 0.20 benefits
> 0.21 as well.
>
> @Jay: Thanks for summing it up so well. I completely agree with your
> viewpoint.
>
> thanks
> dhruba
>
>
> On Mon, May 10, 2010 at 2:06 PM, Jay Booth <[EMAIL PROTECTED]> wrote:
>
>> Given that the 0.20-append branch pretty much already exists
>> unofficially, via IRC, IM and email forwarded patchsets, it seems like
>> giving it an official home is just recognizing the status quo.
>> Especially since 0.21 probably won't be getting rolled out into
>> production everywhere the first day it's officially released.  If the
>> work's going on anyways, I don't see how giving people a shared home
>> hurts matters, if anything it gives them a better shared touchpoint
>> for forward-porting bugfixes to 0.21.
>>
>> A case could be made that by making it more painful to run
>> 0.20-append, more momentum is created towards 0.21 but since Tom is
>> already on top of 21 and seemingly doing an excellent job, and since
>> the HBase community will probably be some of the first people to move
>> to 0.21 anyways, I don't see why having 0.20-append will damage 0.21's
>> momentum at this point.
>>
>>
>>
>> On Mon, May 10, 2010 at 4:21 PM, Michael Segel
>> <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> >> From: [EMAIL PROTECTED]
>> >> Date: Mon, 10 May 2010 10:45:13 -0700
>> >> Subject: Re: Hadoop support for hbase
>> >> To: [EMAIL PROTECTED]
>> >>
>> >
>> >> > The above is a fallacious setup.  How does a branch in 0.20 detract
>> >> > from the 0.21 momentum (The append feature that we'd work on in 0.20
>> >> > branch has little relation to how append works in 0.21).
>> >>
>> >> For what it's worth, though, the majority of the size of the 0.20
>> >> append patch is made up of additional unit tests. I have started
>> >> forward-porting these new tests to the trunk append and it's already
>> >> exposed a number of bugs. So while it's tempting to say that the 0.20
>> >> append is "wasted effort", it really is benefiting the entire
>> >> community and the 0.21 release as well.
>> >>
>> >> -Todd
>> >>
>> >
>> > Sometimes you have to slow down to go faster.
>> >
>> >
>> >
>> > _________________________________________________________________
>> > Hotmail is redefining busy with tools for the New Busy. Get more from
>> your inbox.
>> >
>> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
>>
>
>
>
> --
> Connect to me at http://www.facebook.com/dhruba
>

--
Connect to me at http://www.facebook.com/dhruba