That is not a realistic proposal for 1.0 as far as I can see. There is only a tentative design spec on that issue. I assume we are sticking with Enis' earlier stated intent to get 1.0 out "soon".
> On Jul 7, 2014, at 10:30 AM, Ted Yu <yuzhih...@gmail.com> wrote: > > The following is another candidate for 1.0.0 release > > HBASE-11447 Proposal for a generic transaction API for HBase > > Cheers > > >> 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 >>
