If we do it early and are prepared to revert if we find we come into a situation we cannot work around, then I'd be +1 to pursuing 0.9.2 (even though I was kinda happy I only needed to keep one version installed now that we're not really making 1.5 releases any more).
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Jul 8, 2015 at 11:44 PM, Josh Elser <josh.el...@gmail.com> wrote: > Yeah, that's why I brought it up now. If we're going to do it, we should do > it now and let the shake-down begin. > > I know Hive has been on 0.9.2 for a while now, so I assume it's somewhat ok. > I'm sure we'll be good testers :) > > > Christopher wrote: >> >> Bumping thrift versions scares me... a lot... because of how terrible >> thrift has been about avoiding breakage and/or retaining >> functionality. It seems every time we bump to fix something we want >> fixed, we find many more things broken. >> >> I'd be much more interested in moving to something a bit more reliable >> than Thrift... maybe Java serialization (heavy use of Externalizable) >> or protocol buffers with Netty. But, maybe that's something more for >> 2.0 (or later, since it seems like it'd be a huge effort). Even just >> moving off thrift for the network and leaving it in place for the >> serialization, might be a big improvement in stability. >> >> I'd be far less concerned about bumping thrift if it only affected the >> proxy. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Wed, Jul 8, 2015 at 6:25 PM, Josh Elser<josh.el...@gmail.com> wrote: >>> >>> Also, might be worthwhile to look at thrift 0.9.2 for 1.8 >>> >>> For kerberos, https://issues.apache.org/jira/browse/THRIFT-2660. >>> >>> https://issues.apache.org/jira/browse/THRIFT-2274 might be a concern for >>> us >>> too (would have to check). >>> >>> >>> Josh Elser wrote: >>>> >>>> Some thoughts myself... >>>> >>>> John Vines brought up to me privately the topic of separating out the >>>> RFile code from core. This started making me think about making this >>>> clear for other components like FATE and RandomWalk. These all have some >>>> level of separation, but they often get other things dropped into the >>>> same bucket (e.g. ZK-retry code in FATE, Accumulo implementation classes >>>> in RandomWalk). Maybe there are more things we could do. >>>> >>>> It would be nice to start trying to pull out these >>>> frameworks/sub-projects into discrete packages. I think it would help us >>>> with testing and proper separation of logic. Long term, maybe other >>>> projects would see the value and consider using/adopting them and grow >>>> into their own separately-versioned artifacts. It would be nice to start >>>> these efforts now to eventually reap the benefits. >>>> >>>> >>>> 2.0 and the new client API is a little scary now that we get another >>>> tick closer to it. I know it's been Christopher's brain-child so far >>>> (which is fine -- not meant to be taken in a negative context), but, if >>>> we really do want to adopt it, we should make a concerted effort to >>>> start integrating and reviewing it. Given how far away this seems, 1.8 >>>> and 1.9 could happen (or client API just gets targeted for a 3.0 -- >>>> numbers are just numbers). >>>> >>>> >>>> We have some decent script improvements for 1.8 already in (PID files >>>> _finally_). Would be nice to clean up the rest of the scripts too >>>> (notably the stop scripts need some love). >>>> >>>> >>>> Some other back-burner thoughts: better client API metrics, more >>>> server-side tracing instrumentation, Adam's iterator-stack collapsing >>>> perf ticket, keep tabs on HDFS tracing impl, keep tabs on HTrace's GUI >>>> work, finish the Accumulo monitor rewrite (aka REST server + servlet3). >>>> >>>> - Josh >>>> >>>> Josh Elser wrote: >>>>> >>>>> Thanks to the efforts spearheaded by Christopher and verified by >>>>> everyone else, we now have 1.5.3 and 1.6.3 releases! >>>>> >>>>> To keep the ball rolling, what's next? High level questions that come >>>>> to >>>>> mind... >>>>> >>>>> * When do we do 1.7.1 and/or 1.8.0? >>>>> * What bug-fixes do we have outstanding for 1.7.1? >>>>> * What other minor improvements do people want for 1.8.0? >>>>> * Where does 2.0.0 stand? Should we make a bigger effort to getting the >>>>> new client API stuff Christopher had started into Apache? >>>>> >>>>> Feel free to brainstorm here and/or on JIRA (tagging relevant issues to >>>>> the desired fixVersion) >>>>> >>>>> - Josh
