And by definition of that being a proposed design, there is no implementation to track (yet). There being no implementation, it's hard to see how it makes a 1.0 happening "soon".
Don't misunderstand me to be opposed to the idea or feature, far from it. I don't think Ted did anyone a service bringing it up in the context of 1.0. Already we are on some kind of detour from discussing things where there are patches available. > On Jul 7, 2014, at 10:43 AM, Mikhail Antonov <olorinb...@gmail.com> wrote: > > I thought the scope of HBASE-11447 is to review and refine proposed design, > not to track the implementation of the feature? > > -Mikhail > > > 2014-07-07 10:40 GMT-07:00 Andrew Purtell <andrew.purt...@gmail.com>: > >> 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 > > > > -- > Thanks, > Michael Antonov
