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
