You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Andrew Purtell <ap...@apache.org> on 2017/12/04 19:43:04 UTC
Removing hbase-native-client (HBASE-19419)
We had a recent non-binding veto in a release candidate vote (for 1.1.13)
due to, I think, legitimate confusion over the status of the
hbase-native-client subdirectory in our source tree. This is a self
contained native code connector that is not hooked up to our Maven build.
Therefore there isn't an automated way for our RMs to produce binary
convenience artifacts that include this component. I'm not even sure it is
buildable or functional at this point. It has not been updated for two
years.
Because it is self contained, and in what appears to be an unmaintained
state, I would like to remove it for the 1.4.0 release, therefore from
branch-1.4 and up. Dropping it doesn't represent a compatibility problem in
my view as it isn't hooked up to the build and seems unlikely anyone is
depending on it given we haven't had a single change nor issue reported
against it for two years.
If someone does care about this, it can be resurrected at any time as an
independent GitHub based project.
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: Removing hbase-native-client (HBASE-19419)
Posted by Josh Elser <el...@apache.org>.
Hey Duo,
It's in a general state of DML usability -- you can read and write to
tables. Enis was a big driving force behind this and can probably speak
to more specific questions if you have them.
There are some areas which are still lacking, most notably DDL
operations are not yet implemented. I got involved a little bit to clean
up the build -- some coworkers really helped out and got us moved over
to CMake which really helps folks get up to speed without issue.
I would love to find the time to truly get into the development, but I'm
afraid I'm already stretched pretty thin just trying to keep up with the
2.0 work.
On 12/5/17 8:23 PM, 张铎(Duo Zhang) wrote:
> Oh, it should be 'silence for months'...
>
> 2017-12-06 6:40 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
>
>> Hi Josh, not related to this thread but seems the HBASE-14850 branch has
>> been silence for silence. What's the current status of the native client
>> project?
>>
>> Thanks.
>>
>> 2017-12-06 2:45 GMT+08:00 Josh Elser <el...@apache.org>:
>>
>>> On 12/4/17 11:43 PM, Nick Dimiduk wrote:
>>>
>>>> On Mon, Dec 4, 2017 at 3:28 PM, Josh Elser<el...@apache.org> wrote:
>>>>
>>>> Makes sense to me.
>>>>>
>>>>> *soapbox* I think focusing onhttps://issues.apache.org/jira
>>>>> /browse/HBASE-14850 would be a better use of time than trying to
>>>>> revitalize the old stuff (which I assume has begun to rot).
>>>>>
>>>>
>>>> Is the code under hbase-native-client not the same as that referenced by
>>>> HBASE-14850? The patches on said ticket's children land code under the
>>>> same
>>>> path.
>>>>
>>>
>>> That's correct -- separate "efforts". The stuff Andrew is proposing to
>>> remove is an older client that wasn't (best I can tell) based on
>>> Folly/Wangle like the 14850 stuff is.
>>>
>>
>>
>
Re: Removing hbase-native-client (HBASE-19419)
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Oh, it should be 'silence for months'...
2017-12-06 6:40 GMT+08:00 张铎(Duo Zhang) <pa...@gmail.com>:
> Hi Josh, not related to this thread but seems the HBASE-14850 branch has
> been silence for silence. What's the current status of the native client
> project?
>
> Thanks.
>
> 2017-12-06 2:45 GMT+08:00 Josh Elser <el...@apache.org>:
>
>> On 12/4/17 11:43 PM, Nick Dimiduk wrote:
>>
>>> On Mon, Dec 4, 2017 at 3:28 PM, Josh Elser<el...@apache.org> wrote:
>>>
>>> Makes sense to me.
>>>>
>>>> *soapbox* I think focusing onhttps://issues.apache.org/jira
>>>> /browse/HBASE-14850 would be a better use of time than trying to
>>>> revitalize the old stuff (which I assume has begun to rot).
>>>>
>>>
>>> Is the code under hbase-native-client not the same as that referenced by
>>> HBASE-14850? The patches on said ticket's children land code under the
>>> same
>>> path.
>>>
>>
>> That's correct -- separate "efforts". The stuff Andrew is proposing to
>> remove is an older client that wasn't (best I can tell) based on
>> Folly/Wangle like the 14850 stuff is.
>>
>
>
Re: Removing hbase-native-client (HBASE-19419)
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
Hi Josh, not related to this thread but seems the HBASE-14850 branch has
been silence for silence. What's the current status of the native client
project?
Thanks.
2017-12-06 2:45 GMT+08:00 Josh Elser <el...@apache.org>:
> On 12/4/17 11:43 PM, Nick Dimiduk wrote:
>
>> On Mon, Dec 4, 2017 at 3:28 PM, Josh Elser<el...@apache.org> wrote:
>>
>> Makes sense to me.
>>>
>>> *soapbox* I think focusing onhttps://issues.apache.org/jira
>>> /browse/HBASE-14850 would be a better use of time than trying to
>>> revitalize the old stuff (which I assume has begun to rot).
>>>
>>
>> Is the code under hbase-native-client not the same as that referenced by
>> HBASE-14850? The patches on said ticket's children land code under the
>> same
>> path.
>>
>
> That's correct -- separate "efforts". The stuff Andrew is proposing to
> remove is an older client that wasn't (best I can tell) based on
> Folly/Wangle like the 14850 stuff is.
>
Re: Removing hbase-native-client (HBASE-19419)
Posted by Josh Elser <el...@apache.org>.
On 12/4/17 11:43 PM, Nick Dimiduk wrote:
> On Mon, Dec 4, 2017 at 3:28 PM, Josh Elser<el...@apache.org> wrote:
>
>> Makes sense to me.
>>
>> *soapbox* I think focusing onhttps://issues.apache.org/jira
>> /browse/HBASE-14850 would be a better use of time than trying to
>> revitalize the old stuff (which I assume has begun to rot).
>
> Is the code under hbase-native-client not the same as that referenced by
> HBASE-14850? The patches on said ticket's children land code under the same
> path.
That's correct -- separate "efforts". The stuff Andrew is proposing to
remove is an older client that wasn't (best I can tell) based on
Folly/Wangle like the 14850 stuff is.
Re: Removing hbase-native-client (HBASE-19419)
Posted by Nick Dimiduk <nd...@apache.org>.
On Mon, Dec 4, 2017 at 3:28 PM, Josh Elser <el...@apache.org> wrote:
> Makes sense to me.
>
> *soapbox* I think focusing on https://issues.apache.org/jira
> /browse/HBASE-14850 would be a better use of time than trying to
> revitalize the old stuff (which I assume has begun to rot).
Is the code under hbase-native-client not the same as that referenced by
HBASE-14850? The patches on said ticket's children land code under the same
path.
On 12/4/17 3:00 PM, Andrew Purtell wrote:
>
>> Mike Drob pointed me at HBASE-19176, where hbase-native-client has already
>> been removed from branch-2 given a similar rationale. Therefore I intend
>> to
>> do the same for branch-1.4 and branch-1. On HBASE-19419 Mike asked if
>> hbase-native-client would be removed from branch-1.1, branch-1.2, and
>> branch-1.3 as well. I can do that, but would like to hear from the
>> respective branch RMs if possible first.
>>
>> On Mon, Dec 4, 2017 at 11:43 AM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> We had a recent non-binding veto in a release candidate vote (for 1.1.13)
>>> due to, I think, legitimate confusion over the status of the
>>> hbase-native-client subdirectory in our source tree. This is a self
>>> contained native code connector that is not hooked up to our Maven build.
>>> Therefore there isn't an automated way for our RMs to produce binary
>>> convenience artifacts that include this component. I'm not even sure it
>>> is
>>> buildable or functional at this point. It has not been updated for two
>>> years.
>>>
>>> Because it is self contained, and in what appears to be an unmaintained
>>> state, I would like to remove it for the 1.4.0 release, therefore from
>>> branch-1.4 and up. Dropping it doesn't represent a compatibility problem
>>> in
>>> my view as it isn't hooked up to the build and seems unlikely anyone is
>>> depending on it given we haven't had a single change nor issue reported
>>> against it for two years.
>>>
>>> If someone does care about this, it can be resurrected at any time as an
>>> independent GitHub based project.
>>>
>>> --
>>> Best regards,
>>> Andrew
>>>
>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>> decrepit hands
>>> - A23, Crosstalk
>>>
>>>
>>
>>
>>
Re: Removing hbase-native-client (HBASE-19419)
Posted by Andrew Purtell <ap...@apache.org>.
Thanks for the feedback. I intend to commit HBASE-19419 shortly unless
objection.
On Mon, Dec 4, 2017 at 3:38 PM, Ted Yu <yu...@gmail.com> wrote:
> +1 on removing pre-HBASE-14850
> <https://issues.apache.org/jira/browse/HBASE-14850> stuff.
>
> On Mon, Dec 4, 2017 at 3:28 PM, Josh Elser <el...@apache.org> wrote:
>
> > Makes sense to me.
> >
> > *soapbox* I think focusing on https://issues.apache.org/jira
> > /browse/HBASE-14850 would be a better use of time than trying to
> > revitalize the old stuff (which I assume has begun to rot).
> >
> >
> > On 12/4/17 3:00 PM, Andrew Purtell wrote:
> >
> >> Mike Drob pointed me at HBASE-19176, where hbase-native-client has
> already
> >> been removed from branch-2 given a similar rationale. Therefore I intend
> >> to
> >> do the same for branch-1.4 and branch-1. On HBASE-19419 Mike asked if
> >> hbase-native-client would be removed from branch-1.1, branch-1.2, and
> >> branch-1.3 as well. I can do that, but would like to hear from the
> >> respective branch RMs if possible first.
> >>
> >> On Mon, Dec 4, 2017 at 11:43 AM, Andrew Purtell <ap...@apache.org>
> >> wrote:
> >>
> >> We had a recent non-binding veto in a release candidate vote (for
> 1.1.13)
> >>> due to, I think, legitimate confusion over the status of the
> >>> hbase-native-client subdirectory in our source tree. This is a self
> >>> contained native code connector that is not hooked up to our Maven
> build.
> >>> Therefore there isn't an automated way for our RMs to produce binary
> >>> convenience artifacts that include this component. I'm not even sure it
> >>> is
> >>> buildable or functional at this point. It has not been updated for two
> >>> years.
> >>>
> >>> Because it is self contained, and in what appears to be an unmaintained
> >>> state, I would like to remove it for the 1.4.0 release, therefore from
> >>> branch-1.4 and up. Dropping it doesn't represent a compatibility
> problem
> >>> in
> >>> my view as it isn't hooked up to the build and seems unlikely anyone is
> >>> depending on it given we haven't had a single change nor issue reported
> >>> against it for two years.
> >>>
> >>> If someone does care about this, it can be resurrected at any time as
> an
> >>> independent GitHub based project.
> >>>
> >>> --
> >>> Best regards,
> >>> Andrew
> >>>
> >>> Words like orphans lost among the crosstalk, meaning torn from truth's
> >>> decrepit hands
> >>> - A23, Crosstalk
> >>>
> >>>
> >>
> >>
> >>
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: Removing hbase-native-client (HBASE-19419)
Posted by Ted Yu <yu...@gmail.com>.
+1 on removing pre-HBASE-14850
<https://issues.apache.org/jira/browse/HBASE-14850> stuff.
On Mon, Dec 4, 2017 at 3:28 PM, Josh Elser <el...@apache.org> wrote:
> Makes sense to me.
>
> *soapbox* I think focusing on https://issues.apache.org/jira
> /browse/HBASE-14850 would be a better use of time than trying to
> revitalize the old stuff (which I assume has begun to rot).
>
>
> On 12/4/17 3:00 PM, Andrew Purtell wrote:
>
>> Mike Drob pointed me at HBASE-19176, where hbase-native-client has already
>> been removed from branch-2 given a similar rationale. Therefore I intend
>> to
>> do the same for branch-1.4 and branch-1. On HBASE-19419 Mike asked if
>> hbase-native-client would be removed from branch-1.1, branch-1.2, and
>> branch-1.3 as well. I can do that, but would like to hear from the
>> respective branch RMs if possible first.
>>
>> On Mon, Dec 4, 2017 at 11:43 AM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> We had a recent non-binding veto in a release candidate vote (for 1.1.13)
>>> due to, I think, legitimate confusion over the status of the
>>> hbase-native-client subdirectory in our source tree. This is a self
>>> contained native code connector that is not hooked up to our Maven build.
>>> Therefore there isn't an automated way for our RMs to produce binary
>>> convenience artifacts that include this component. I'm not even sure it
>>> is
>>> buildable or functional at this point. It has not been updated for two
>>> years.
>>>
>>> Because it is self contained, and in what appears to be an unmaintained
>>> state, I would like to remove it for the 1.4.0 release, therefore from
>>> branch-1.4 and up. Dropping it doesn't represent a compatibility problem
>>> in
>>> my view as it isn't hooked up to the build and seems unlikely anyone is
>>> depending on it given we haven't had a single change nor issue reported
>>> against it for two years.
>>>
>>> If someone does care about this, it can be resurrected at any time as an
>>> independent GitHub based project.
>>>
>>> --
>>> Best regards,
>>> Andrew
>>>
>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>> decrepit hands
>>> - A23, Crosstalk
>>>
>>>
>>
>>
>>
Re: Removing hbase-native-client (HBASE-19419)
Posted by Josh Elser <el...@apache.org>.
Makes sense to me.
*soapbox* I think focusing on
https://issues.apache.org/jira/browse/HBASE-14850 would be a better use
of time than trying to revitalize the old stuff (which I assume has
begun to rot).
On 12/4/17 3:00 PM, Andrew Purtell wrote:
> Mike Drob pointed me at HBASE-19176, where hbase-native-client has already
> been removed from branch-2 given a similar rationale. Therefore I intend to
> do the same for branch-1.4 and branch-1. On HBASE-19419 Mike asked if
> hbase-native-client would be removed from branch-1.1, branch-1.2, and
> branch-1.3 as well. I can do that, but would like to hear from the
> respective branch RMs if possible first.
>
> On Mon, Dec 4, 2017 at 11:43 AM, Andrew Purtell <ap...@apache.org> wrote:
>
>> We had a recent non-binding veto in a release candidate vote (for 1.1.13)
>> due to, I think, legitimate confusion over the status of the
>> hbase-native-client subdirectory in our source tree. This is a self
>> contained native code connector that is not hooked up to our Maven build.
>> Therefore there isn't an automated way for our RMs to produce binary
>> convenience artifacts that include this component. I'm not even sure it is
>> buildable or functional at this point. It has not been updated for two
>> years.
>>
>> Because it is self contained, and in what appears to be an unmaintained
>> state, I would like to remove it for the 1.4.0 release, therefore from
>> branch-1.4 and up. Dropping it doesn't represent a compatibility problem in
>> my view as it isn't hooked up to the build and seems unlikely anyone is
>> depending on it given we haven't had a single change nor issue reported
>> against it for two years.
>>
>> If someone does care about this, it can be resurrected at any time as an
>> independent GitHub based project.
>>
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>> - A23, Crosstalk
>>
>
>
>
Re: Removing hbase-native-client (HBASE-19419)
Posted by Andrew Purtell <ap...@apache.org>.
Mike Drob pointed me at HBASE-19176, where hbase-native-client has already
been removed from branch-2 given a similar rationale. Therefore I intend to
do the same for branch-1.4 and branch-1. On HBASE-19419 Mike asked if
hbase-native-client would be removed from branch-1.1, branch-1.2, and
branch-1.3 as well. I can do that, but would like to hear from the
respective branch RMs if possible first.
On Mon, Dec 4, 2017 at 11:43 AM, Andrew Purtell <ap...@apache.org> wrote:
> We had a recent non-binding veto in a release candidate vote (for 1.1.13)
> due to, I think, legitimate confusion over the status of the
> hbase-native-client subdirectory in our source tree. This is a self
> contained native code connector that is not hooked up to our Maven build.
> Therefore there isn't an automated way for our RMs to produce binary
> convenience artifacts that include this component. I'm not even sure it is
> buildable or functional at this point. It has not been updated for two
> years.
>
> Because it is self contained, and in what appears to be an unmaintained
> state, I would like to remove it for the 1.4.0 release, therefore from
> branch-1.4 and up. Dropping it doesn't represent a compatibility problem in
> my view as it isn't hooked up to the build and seems unlikely anyone is
> depending on it given we haven't had a single change nor issue reported
> against it for two years.
>
> If someone does care about this, it can be resurrected at any time as an
> independent GitHub based project.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk