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 <[email protected]> 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 somehow > 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 of > the points raised in this discussion, especially the one about having > multiple parties try it out on their use cases. But nobody did, so I > eventually 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 patches for review. They sat there untouched for many days. Now > I'm agitating for inclusion because otherwise it seems this feature would be > ignored. At the same time, we have received comment the coprocessor framework > is exciting, 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. > > - Andy > > > > > >
