>> That's not true, we found issues and filed JIRAs. As to how significant >> they are or not, I defer to the JIRAs for discussion.
Majority of JIRAs filed are trivial. If you do not agree, please post a link to bugs you consider serious. The rest are requests for *new functionality* which SF needs. And most of them (new features) can be implemented in 1-2 months timeframe. THESE are NEW FEATURE requests If you think that partial table backups and partial table restore are BASIC functionalities - I do not agree with you. On Wed, Nov 1, 2017 at 12:20 PM, Andrew Purtell <[email protected]> wrote: > > Can you explain please how did you guys manage to file multiple JIRAs > (trivials mostly) without testing backup/restore? > > What the fuck, Vlad. > > Obviously we did some testing. > > You said "Salesforce team has conducted independent testing and found no > issues with a functionality to my best knowledge." > > That's not true, we found issues and filed JIRAs. As to how significant > they are or not, I defer to the JIRAs for discussion. > > > On Wed, Nov 1, 2017 at 12:17 PM, Vladimir Rodionov <[email protected] > > > wrote: > > > >>I dont' want to get drawn into another unfriendly argument, but this is > > >>simply not true. We filed a bunch of JIRAs including one with serious > > >>concerns about scalability. > > > > Can you explain please how did you guys manage to file multiple JIRAs > > (trivials mostly) > > without testing backup/restore? > > > > What you are referring to is not a scalability (its scalable), but > > *possible* performance issue of incremental backup > > We have JIRA and partial patch to address this issue HBASE-17825. This > will > > definitely make it into beta-1. > > > > > > On Wed, Nov 1, 2017 at 12:00 PM, Stack <[email protected]> wrote: > > > > > On Wed, Nov 1, 2017 at 11:53 AM, Josh Elser <[email protected]> wrote: > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Grand. > > > > > > > > > > > > > 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. > > > > > > > > > > > I'll take a look sir. > > > > > > > > > > > > > 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. > > > > > > > > > > > Sean filed HBASE-18817 <https://issues.apache.org/ > > jira/browse/HBASE-18817> > > > with > > > the result of that discussion. > > > > > > > > > > > > > Now that I'm thinking about it, I wonder if that's actually the > proper > > > > route forward for hbase-native-client too... > > > > > > > > > > > And backup? > > > > > > Thanks Josh. > > > St.Ack > > > > > > > > > > > > > > > > What else? > > > >> > > > >> Thanks, > > > >> St.Ack > > > >> > > > >> > > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
