On 11/1/17 1:32 PM, Stack wrote:
I want to purge the below list of modules, features, and abandoned code
from branch-2 before we make a beta-1 (4-5 weeks I'm thinking). Lets
discuss. Some are already scheduled for removal but listing anyways for
completeness sake. Pushback or other suggestions on what else we should
remove are welcome.

Distributed Log Replay: Just last week, I heard of someone scheduling
testing of DLR. We need to better message that this never worked and was/is
not supported. It's a good idea that we should implement but built on a
different chasis (procedurev2?). Meantime, DLR is still scattered about the
codebase as an optional code path. Lets remove it.

hbase-native-client: It is not done and won't be for 2.0.0. It can come in
later when it is done (2.1 or 3.0).

I think that's fine. It's in a state where people can use it to do basic read-write operations. While it would be nice to have this go out to folks who would test it, forcing that to happen via inclusion in a release isn't necessary.

hbase-prefix-tree: A visionary effort that unfortunately has had no uptake
since its original wizard-author moved on. I don't believe it is used
anywhere. It has become a drag as global changes need to be applied in here
too by folks who are not up on how it works probably doing damage along the
way. This is like DLR in it should be first class but we've not done the
work to keep it up.

hbase-backup: Not done and it doesn't look like it will be done for beta-1.
It can come in later in a 2.1 or 3.0 when it is finished.

Ditto to what Vlad said. AFAIK, just the one issue remains: HBASE-17852. Didn't want to bother you with it while you were head-down on alpha4, Stack; can you take a look at the explanation Vlad has put up there so we can try to move it forward? I don't think this needs to be punted out.

hbase-spark: Purging this makes me tear-up.

We had a talk about this a while back, didn't we? I forget if we had consensus about having it follow its own release schedule (rather than tying it to HBase "internals") -- I think I suggested that anyways :P.

Now that I'm thinking about it, I wonder if that's actually the proper route forward for hbase-native-client too...

What else?

Thanks,
St.Ack

Reply via email to