hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Code review request for hbase-4120 table priority
Date Tue, 13 Dec 2011 00:36:51 GMT
By the way, -1 to this as a criteria:

> If it's completely a coprocessor, then it seems we should let it bake
> on github and only incorporate in core if we find that a number of the
> core HBase users are using it in production. 

 
HBase as a project should not have as a criteria for inclusion of some feature that Cloudera
and SU and Facebook run it. Core managed to escape Yahoo. Let's not run history in reverse
here in HBase land. And, actually, this makes it worse, because the the occurrence that
a number of core HBase users (multiple) will all need something is substantially less likely
than if one might find it useful; or, maybe, only users outside of those with such self-appointed
attitude, yet perhaps a community multiples in size of "core users". 

Best regards,


   - Andy


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


----- Original Message -----
> From: Andrew Purtell <apurtell@apache.org>
> To: "dev@hbase.apache.org" <dev@hbase.apache.org>
> Cc: 
> Sent: Monday, December 12, 2011 4:30 PM
> Subject: Re: Code review request for hbase-4120 table priority
> 
> HBASE-4120 deals with only the RPC prioritization parts. This cannot be 
> implemented as a coprocessor.
> 
>>  If it's completely a coprocessor, then it seems we should let it bake
>>  on github and only incorporate in core if we find that a number of the
>>  core HBase users are using it in production.  
> 
> 
> The addition of the coprocessor framework is from my point of view a double 
> edged sword. It can be a tool to clarify core and reduce maintenance burden on 
> the community for various boutique functions. On the other hand it can be used 
> to freeze further feature development and leave users who need such features out 
> in the cold to go their own way or make a private fork. 
> 
> I've become aware of several private forks of HDFS and HBase. Too bad. A 
> pooling of dev resources would have almost surely have been better.
> 
> HBASE-4120 and successor issues are / will be an attempt to take what runs in 
> production at Taobao and upstream it. They could just do a code drop on GitHub 
> of what they have now. Would be much easier than reimplementing it as a 
> coprocessor. However they have incentive here to give back to upstream, 
> additional co-development with the community, for inclusion of their work in the 
> distribution. What is the incentive if we want them to make the reimplementation 
> effort only to then just drop that on GitHub?
> 
> There are some cases where it would benefit all users to include 
> coprocessor-based features in tree: Like security. Perhaps like constraints. 
> Like the isolation/allocation stuff, for perhaps 0.94. Perhaps secondary 
> indexing. In all of these cases, though the majority of the implementation is as 
> coprocessor, there must be some changes to core -- to the coprocessor framework, 
> generally -- to support it. A coprocessor can be included in the tree as a maven 
> module. Without such inclusion, the rationale for not dropping the enabling 
> logic in core may be lacking ... "oh, this just supports some GitHub 
> thing".
> 
> Best regards,
> 
> 
>    - Andy
> 
> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via 
> Tom White)
> 
> 
> ----- Original Message -----
>>  From: Todd Lipcon <todd@cloudera.com>
>>  To: dev@hbase.apache.org
>>  Cc: 
>>  Sent: Monday, December 12, 2011 4:03 PM
>>  Subject: Re: Code review request for hbase-4120 table priority
>> 
>>  If it's completely a coprocessor, then it seems we should let it bake
>>  on github and only incorporate in core if we find that a number of the
>>  core HBase users are using it in production. Am I misunderstanding the
>>  implementation? (haven't looked at the most recent patch)
>> 
>>  -Todd
>> 
>>  On Mon, Dec 12, 2011 at 3:50 PM,  <yuzhihong@gmail.com> wrote:
>>>   Waiting for review comments from other committers.
>>>   The implementation is pluggable by using coprocessors.
>>> 
>>>   Cheers
>>> 
>>> 
>>> 
>>>   On Dec 12, 2011, at 5:43 PM, Stack <stack@duboce.net> wrote:
>>> 
>>>>   On Mon, Dec 12, 2011 at 6:43 AM,  <yuzhihong@gmail.com> 
> wrote:
>>>>>   Hi,
>>>>>   4120 has gone through more than 20 revisions.
>>>>> 
>>>>>   Please provide your comments.
>>>>> 
>>>>>   I plan to integrate it this week.
>>>>> 
>>>> 
>>>>   I'd suggest hold on commit until some other committers have 
> had a
>>>>   looksee.  This is an important feature that we need to get right 
> and
>>>>   there is no need to rush it in.
>>>> 
>>>>   Thanks Ted (and thanks for the reviews so far),
>>>>   St.Ack
>> 
>> 
>> 
>>  -- 
>>  Todd Lipcon
>>  Software Engineer, Cloudera
>> 
> 

Mime
View raw message