This ticket has only open subtasks, ie nothing in 'patch available'. I assume you mean HBASE-10168. We'll see about getting you some reviews, but you should also go about formatting the patch for buildbot. Also, since your 3 reviews are individually 100+k, you should consider breaking them into three separate tickets.
my 2¢ -n On Mon, Jul 7, 2014 at 12:01 PM, Aditya <adityakish...@gmail.com> wrote: > Sorry about that. > > Here is the umbrella JIRA https://issues.apache.org/jira/browse/HBASE-1015 > > > On Mon, Jul 7, 2014 at 10:05 AM, Nick Dimiduk <ndimi...@gmail.com> wrote: > >> Would you mind including the JIRA numbers along with the request? >> >> Thanks, >> Nick >> >> >> 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 >>> > > >>> > >>> >> >> >
