Because I for one might well want to run RS groups in production with branch-1 code without waiting for or dealing with the other stuff coming in any 2.0. I might go so far as to fork if we end up needing it and a backport is prevented by any intransigent community element.
> On Mar 16, 2016, at 4:07 PM, Elliott Clark <ecl...@apache.org> wrote: > > I just don't see a why we would back port. We're going to release a 2.0 > when things are ready. It will be a major feature release. Region server > groups is a major feature. Backporting to branch-1 seems like an end run > around what sem ver is supposed to mean (not the api guarantees, the actual > meaning). > > Backporting major features is a bad habit that the Hadoop community seems > to have. We shouldn't follow their lead. > > On Wed, Mar 16, 2016 at 2:51 PM, Andrew Purtell <apurt...@apache.org> wrote: > >>> Are we being more stringent with 0.98 because it is expected to be more >> stable than a 1.x release? >> >> I am not being more stringent with 0.98. A backport to branch-1 can be >> justified IMHO because there appears to be active interest in having it >> there to deploy out into production somewhere. Is this also the case for >> 0.98? As you may recall I accepted ZK-less assignment into 0.98 because >> Yahoo indicated they'd run the code, so as a result it would get regular >> use. It was a decision that wouldn't make sense if there wasn't going to be >> active use and upkeep. Otherwise we increase risk and make some users >> nervous (I seem to recall Cloudera did not pick up the ZK less assignment >> change back when they were still on 0.98) without improved utility for >> other users in trade. Just my thinking on the matter. >> >> >> On Wed, Mar 16, 2016 at 2:24 PM, Francis Liu <tof...@apache.org> wrote: >> >>>> performance tests focused on the impact of the feature on those who >>> don't want it. >>> Andy and Ted, Given that this code does not touch the write path or the >>> read path at all it would seem practical to skip read/write perf tests >> (ie >>> YCSB, PE, etc)? >>>> where the result will go into someone's production. >>> Are we being more stringent with 0.98 because it is expected to be more >>> stable than a 1.x release? >>> >>> >>> On Wednesday, March 16, 2016 12:11 PM, Ted Yu <yuzhih...@gmail.com> >>> wrote: >>> >>> >>> bq. same things I asked for MOB: Functional, stability, and performance >>> tests focused on the impact of the feature on those who don't want it. >>> >>> +1 on the above. >>> >>> On Wed, Mar 16, 2016 at 11:14 AM, Andrew Purtell <apurt...@apache.org> >>> wrote: >>> >>>> I would like to see the same things I asked for MOB: Functional, >>> stability, >>>> and performance tests focused on the impact of the feature on those who >>>> don't want it. Can use the usual suspects: PE, LTT, YCSB, our ITs. >> Given >>>> how 6721 has been implemented I suspect favorable results will be easy >> to >>>> obtain. >>>> >>>> I think we would like to see a backport to branch-1 because we will be >>>> bringing our production up to a 1.x soon. >>>> >>>> Its fair to consider a backport to 0.98 but as RM for that branch I'd >>> like >>>> to see it go into branch-1 first and also have a case where the result >>> will >>>> go into someone's production. >>>> >>>> >>>> On Wed, Mar 16, 2016 at 10:15 AM, Francis Liu <tof...@ymail.com.invalid >>> >>>> wrote: >>>> >>>>> Hi, >>>>> HBASE-6721 is now committed to trunk. It'd be great if it can be >>>>> backported to 1.x and 0.98 so that we can use it internally as well >> as >>>> push >>>>> up features and fixes. We have been running an internal version for >>>> around >>>>> 4 years. There's seems to be interest (HW, Bloomberg, Salesforce, >> etc). >>>>> Also given how modular the code is. There's barely any effect in >>> existing >>>>> code paths. >>>>> Seeding the criteria with Andy's suggestions in jira: >>>>> 1. Stability - Unit tests and ?2. functional3. Performance - >> Read/write >>>>> path was not affected. Some small changes related to assignment. >>>>> Thanks, >>>>> Francis >>>> >>>> >>>> -- >>>> Best regards, >>>> >>>> - Andy >>>> >>>> Problems worthy of attack prove their worth by hitting back. - Piet >> Hein >>>> (via Tom White) >> >> >> >> -- >> Best regards, >> >> - Andy >> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein >> (via Tom White) >>
