hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98
Date Thu, 17 Mar 2016 06:23:02 GMT
I remember explicitly saying I was not against a backport of the MOB feature. You are misrepresenting
my position a bit. Sure, I'm a skeptic. Not a big deal because I don't think we can or should
seek a blanket rule. Sometimes a feature will have sufficient interest and applicability that
a backport is worth considering, and then there's a question of what kind of risk the changes
envisioned carry. RS groups as implemented are low risk. Meanwhile MOB is highly invasive.
I think RS groups would have two large production users soon after introduction into branch-1.
I'm not sure about MOB. They are worth consideration on their own merits and on user demand
for them. 

Another thing we could do is get 2.0 started right now. Whatever major that doesn't make the
cut could go into 3.0. I think the requests for these backports are coming because there is
no near time horizon for a 2.0 release. So set it soon?


> On Mar 16, 2016, at 9:27 PM, Elliott Clark <eclark@apache.org> wrote:
> 
> On Wed, Mar 16, 2016 at 6:26 PM, Andrew Purtell <andrew.purtell@gmail.com>
> wrote:
> 
>> 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.
> 
> 
> This is the same email that I sent for MOB. Which you agreed with then. But
> not now. There's nothing substantively different about this feature that
> makes it different from any other feature. It's a large change that wasn't
> there in 1.X line.
> 
> I would like backups, and procedure v2 in 1.x. However even if it landed
> tomorrow they shouldn't be back ported as it's a large feature that's not
> ready. If we want anyone to ever upgrade major versions, then the new
> features have to come along with the new apis. Other wise we will end up in
> the same state that Hadoop has.

Mime
View raw message