Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of saint.ack@gmail.com
 designates 74.125.82.51 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=sO6kfE+Q5RMijodo8giZRiOGI/rnSOdJPy/VonhVOVBgaZgy+XU0NX3wfihkioS84Q
         5Upv0tb2TSZm1EPZzMtNkijFf29yCt8ldBFD5sR/EVuk+vJOURLDvCIOyy3VO3HuOVMi
         CGoNeTSW9mDCjX7gJReSNj+jYNaGa2yPtIQsI=
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: <150659.82660.qm@web65509.mail.ac4.yahoo.com>
References: <AANLkTimbVMQM+SmCAKCggzL7M9iA6c9_TmygEnPiue4T@mail.gmail.com>
	<150659.82660.qm@web65509.mail.ac4.yahoo.com>
Date: Wed, 6 Oct 2010 11:31:38 -0700
Message-ID: <AANLkTinbJzAXPaiCBrDtO5gROE8HDjngpubL470Ac9py@mail.gmail.com>
Subject: Re: dynamic RPC and coprocessor changes
From: Stack <stack@duboce.net>
To: dev@hbase.apache.org, apurtell@apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I spent some time reviewing the two fat patches that are up in
review.hbase.org.  I haven't finished either review yet -- they are
large patches (and sorry for taking so long to get around to the
reviews Andrew, Gary and 	Mingjie) -- but here's a few high-level
observations.  Please correct me if I'm off in any way.

+ Its a fat, quality contrib. of some really sweet functionality
+ It looks like both of the big patches have to go in for the
functionality to be complete (2001+2002)
+ There looks to me to be work to do yet, at least from what I've
seen.  Nothing that one or two more rounds of patch+review couldn't
fix but in at least a few cases, there are currently IMO blockers on
commit (The CP-specific but generically named classes in client
package that Gary is working on and some base class namings in CP
package).
+ The patch+review cycle will take some time to complete not least
because the patches are big -- a week under normal circumstances I'd
say and IMO this 'opportunity' where CP is put under the spotlight
should not be rushed -- but at this particular time there are
'distractions' that will likely push this out namely core bug-fixing,
testing, and stabilizations for 0.90 and HW so elapsed time will go
up.
+ CP while super-cool is ancillary to HBase core

My fear is that adding in CP now will push out 0.90 by some
non-inconsequential amount of time.

My preference would be to not include CP in 0.90.

If 'exposure' is the justification for getting CP into 0.90 and it is
admittedly still malleable -- is this right? -- subject to change and
'experimental', doesn't it better belong in TRUNK post a 0.90 branch?
We could commit as soon as end-of-day today if was wanted?  Having it
in branch brings exposure and shows hbase projects committment to CP?

St.Ack


On Wed, Oct 6, 2010 at 9:14 AM, Andrew Purtell <apurtell@apache.org> wrote:
>> From: Todd Lipcon
>>
>> If we could hold up the 0.90 release for enough time to do
>> a dev release or two with coprocessors, I'd be all for it.
>> But given the aims of the release, I don't think coprocessors
>> are a blocking feature.
>
> This position makes sense when viewed through the lens of your priorities=
. However it also confirms my suspicion coprocessors as a feature is someho=
w considered second class.
>
> That said, I do acknowledge I let coprocessors sit for a while so someone=
 else could pick up what was on jira and iterate on it. Anticipating many o=
f the points raised in this discussion, especially the one about having mul=
tiple parties try it out on their use cases. But nobody did, so I eventuall=
y tasked our guys to finish it. We also agreed to base our security work on=
 it. So coprocessors blocks all of our stuff now. Then we put coprocessor p=
atches for review. They sat there untouched for many days. Now I'm agitatin=
g for inclusion because otherwise it seems this feature would be ignored. A=
t the same time, we have received comment the coprocessor framework is exci=
ting, which is incongruent.
>
>> I think, though, that for this kind of large new framework,
>> we want to have some experience actually trying to use it -
>> having at least one other person/company outside of
>> TrendMicro use the framework to build a non-toy app is the
>> requirement in my mind.
>
> That would be great, but it is totally out of my control, so making it a =
precondition for inclusion seems somewhat unfair.
>
> =A0 - Andy
>
>
>
>
>
>