I also don't see why we can't have the spark connector module in a 1.x release. 
I know our internal users would be delighted to have it available. 

> On Mar 17, 2016, at 9:00 AM, Matteo Bertozzi <theo.berto...@gmail.com> wrote:
> 
> spark is no different than RS group for this discussion.
> We forced francis to move everything in a module and use coprocessors to be
> external as possible.
> so, if RS group is not going to a 1.x we should have spark not going in for
> the same reason.
> 
> MOB is deep into HRegion and all the other stuff even if everything is
> under if isMobCF.
> so, I see why we may not want it just by looking at the code.
> API, and usefulness is another thing to consider but it doesn't look like
> we are discussing this in this thread.
> 
> 
>> On Thu, Mar 17, 2016 at 8:53 AM, Ted Yu <yuzhih...@gmail.com> wrote:
>> 
>> For Spark, backporting to branch-1 makes sense since
>> 
>> it is in hbase-spark module - only adds one line to root pom.xml.
>> there has been frequent user query for when hbase-spark would be in an
>> hbase release
>> 
>> On Thu, Mar 17, 2016 at 8:26 AM, Matteo Bertozzi <theo.berto...@gmail.com>
>> wrote:
>> 
>>> If we cut master now we have
>>> - no rolling upgrade (am switched to zkless only and the other code was
>>> removed)
>>> - no api compatibility (we removed the deprecated)
>>> - Offheaping on the read path
>>> - Spark
>>> - MOB
>>> - RS Groups
>>> - some other stuff...
>>> 
>>> is that worth a major?
>>> The offheaping work is probably the one that cannot be backported and it
>>> may be nice to have.
>>> but stuff like spark, mob and RS Groups can be in a 1.x and avoid
>> migration
>>> pain, and those are probably the ones that some people wants to try now.
>>> 
>>> If we have a 2.0 for features like Spark, Mob and RS Groups I'd like to
>>> have it based on branch-1. At least users can move there without having
>> to
>>> worry about compatibility, even if the version number itself will
>> probably
>>> force the users to stick with the 1.x because the assumption is that
>>> something will break or there is a migration required.
>>> 
>>> On Thu, Mar 17, 2016 at 8:05 AM, Andrew Purtell <
>> andrew.purt...@gmail.com>
>>> wrote:
>>> 
>>>> I don't think we need to do a major for RS groups.
>>>> 
>>>> I do think Elliott's points can be addressed by getting a 2.0 out the
>>> door
>>>> soon containing whatever we have on deck now to go in.
>>>> 
>>>> Probably not going to satisfy everyone here - but maybe?
>>>> 
>>>> 
>>>>> On Mar 17, 2016, at 7:48 AM, Matteo Bertozzi <
>> theo.berto...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> Why MOB and RegionServer Groups should be in a new major version and
>>>> stuff
>>>>> like the new RPC queue (HBASE-15136), date based tiered compactions
>>>>> (HBASE-15181), special handling for system tables WALs (HBASE-13557),
>>>> keep
>>>>> table state in meta (HBASE-13017) or the Region Normalizer
>>> (HBASE-13103)
>>>>> are considered for or already in 1.x?
>>>>> 
>>>>> to me, and probably most of the users, a new Major version means that
>>>> APIs
>>>>> will break, wire may break, there may be an upgrade of some sort and
>> so
>>>> on.
>>>>> which is not true for MOB and RS groups.
>>>>> 
>>>>> In case we do a major for RS groups and Mob will that still based on
>>> the
>>>>> 1.x branch?
>>>>> 
>>>>> On Wed, Mar 16, 2016 at 11:23 PM, Andrew Purtell <
>>>> andrew.purt...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> 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 <ecl...@apache.org>
>>> wrote:
>>>>>>> 
>>>>>>> On Wed, Mar 16, 2016 at 6:26 PM, Andrew Purtell <
>>>>>> andrew.purt...@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.
>> 

Reply via email to