I was hoping to get some initial comments before attaching patches for the build boat.
I have broken the entire code into 5 patch sets, layered in a sequnce, each focusing on a particular area (public headers/JNI implementation/Examples+unit test, etc) for the ease of review. https://reviews.apache.org/r/23175/ https://reviews.apache.org/r/23176/ https://reviews.apache.org/r/23177/ https://reviews.apache.org/r/23178/ https://reviews.apache.org/r/23179/ These are also available as a sequence of patches as the pull request <https://github.com/apache/hbase/pull/1>. Only the last patch hooks everything to the HBase build process (optionally) and hence I was thinking of squashing these separate patches into a single patch to be submitted for build. On Wed, Jul 9, 2014 at 11:32 AM, Nick Dimiduk <ndimi...@gmail.com> wrote: > This ticket has only open subtasks, ie nothing in 'patch available'. I > assume you mean HBASE-10168. We'll see about getting you some reviews, but > you should also go about formatting the patch for buildbot. Also, since > your 3 reviews are individually 100+k, you should consider breaking them > into three separate tickets. > > my 2¢ > -n > > > On Mon, Jul 7, 2014 at 12:01 PM, Aditya <adityakish...@gmail.com> wrote: > >> Sorry about that. >> >> Here is the umbrella JIRA >> https://issues.apache.org/jira/browse/HBASE-1015 >> >> >> On Mon, Jul 7, 2014 at 10:05 AM, Nick Dimiduk <ndimi...@gmail.com> wrote: >> >>> Would you mind including the JIRA numbers along with the request? >>> >>> Thanks, >>> Nick >>> >>> >>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <adityakish...@gmail.com> wrote: >>> >>>> Do we want to have the C APIs part of 1.0.0 release. I had posted few >>>> patches and a set of review request sometime last week. >>>> >>>> >>>> On Fri, Jul 4, 2014 at 1:21 AM, Enis Söztutar <enis....@gmail.com> >>>> wrote: >>>> >>>> > On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <olorinb...@gmail.com >>>> > >>>> > wrote: >>>> > >>>> > > Moved ZK watcher & listener subtask out of scope HBASE-10909. Enis >>>> - with >>>> > > that, I guess HBASE-10909 can be marked in branch-1? >>>> > > >>>> > >>>> > Sounds good. >>>> > >>>> > >>>> > > >>>> > > HBASE-11464 - this is the jira where I'll capture tasks to abstract >>>> hbase >>>> > > client from ZK (mostly it would be post-1.0 work). >>>> > > >>>> > >>>> > Not sure whether we can make it fully backwards compatible with 1.0 >>>> > clients. I guess we will see when the patches are done. >>>> > >>>> > >>>> > > >>>> > > Thanks, >>>> > > Mikhail >>>> > > >>>> > > >>>> > > 2014-07-03 12:52 GMT-07:00 Stack <st...@duboce.net>: >>>> > > >>>> > > > On Thu, Jul 3, 2014 at 12:25 PM, Mikhail Antonov < >>>> olorinb...@gmail.com >>>> > > >>>> > > > wrote: >>>> > > > >>>> > > > > Guys, >>>> > > > > >>>> > > > > getting back to ZK abstraction work w.r.t. release 1.0 and >>>> > thereafter, >>>> > > > some >>>> > > > > status update. So as we're getting closer to complete >>>> HBASE-10909, it >>>> > > > looks >>>> > > > > like the steps may be like this: >>>> > > > > >>>> > > > > - there are 2 subtasks out there not closed yet, one of which >>>> is >>>> > about >>>> > > > log >>>> > > > > splitting (and Sergey S has submitted a patch for review), >>>> another is >>>> > > > > abstraction of ZK watcher (this is what I've been working on in >>>> the >>>> > > > > background; but after sketching the patch it seems like without >>>> being >>>> > > > able >>>> > > > > to modify the control flows and some changes in the module >>>> structure, >>>> > > > it'd >>>> > > > > be a lot of scaffolding code not really simplifying current >>>> code). So >>>> > > I'd >>>> > > > > propose to descope abstraction of ZK watcher jira (HBASE-11073), >>>> > > namely: >>>> > > > > convert it to top-level JIRA and continue to work on it >>>> separately; >>>> > > > rename >>>> > > > > HBASE-10909 to "ZK abstraction: phase 1", and mark it as closed >>>> as >>>> > soon >>>> > > > as >>>> > > > > log splitting jira is completed. This way HBASE-10909 fits to >>>> > branch-1. >>>> > > > > >>>> > > > >>>> > > > Sounds good to me. >>>> > > > >>>> > > > >>>> > > > > - secondly, in the discussion to the CatalogTracker patch, we >>>> > started >>>> > > > > talking about modifying client to not know about ZK, but rather >>>> keep >>>> > > the >>>> > > > > location of current masters and talk to them using RPC calls. >>>> This >>>> > work >>>> > > > can >>>> > > > > not go into branch-1, as it involves invasive changes in client >>>> > > including >>>> > > > > new RPC. As I understand the branching schema now, those >>>> changes can >>>> > go >>>> > > > to >>>> > > > > master branch, we just don't merge them to branch-1, and >>>> depending on >>>> > > > their >>>> > > > > completeness we can pull them to 1.1 release or so. >>>> > > > > >>>> > > > >>>> > > > You have it right Mikhail. >>>> > > > >>>> > > > St.Ack >>>> > > > >>>> > > >>>> > > >>>> > > >>>> > > -- >>>> > > Thanks, >>>> > > Michael Antonov >>>> > > >>>> > >>>> >>> >>> >> >
