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 > > > > > >
