We're on the same page, Enis. Cheers
On Mon, Jul 7, 2014 at 10:56 AM, Enis Söztutar <e...@apache.org> wrote: > I think it is fair to say for both C API and transaction API that it should > be ok to include them if they are ready before the time to cut the 1.0 RC. > If not, I do not want to hold the release waiting for those. > > Enis > > > On Mon, Jul 7, 2014 at 10:50 AM, Andrew Purtell <andrew.purt...@gmail.com> > wrote: > > > 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 > > >
