On Wed, Nov 1, 2017 at 7:45 PM, Josh Elser <[email protected]> wrote:
> (This one has been sitting on my mind while doing some non-computer-y > things this evening; admittedly, in an attempt to NOT think about it. Go > figure. Let me add to Vlad's previous) > > I want to say I still respect that it's the RM's prerogative to be the > hammer on what makes a release and what doesn't. I don't want to undermine > that. > > I know we are saying "Bug fixes ONLY" for beta-1, I'm pretty sure we > already have some stuff ear-marked to do that doesn't meet that bar. Is > writing a test and collecting docs (as Vlad suggests) worthwhile to try to > do? In other words, if it's not de-stabilizing the rest of the code and not > holding up beta-1, will a request to add said docs+test be accepted to > avoid a revert from 2.0.0? > > If the 4-5 weeks original estimated is possible, we'd need to get > something in place in more like 3-4 weeks. Again, a question of how strict > we are going to be as we get closer and closer. > > We can revisit in 3-4 weeks, of course. December 1st at the outside? That said, going by just this thread alone, I'll be really surprised if backup makes beta-1. There seems to be a gap in understanding when we talk of 'feature complete'. And the bar is higher for a feature like backup as has been said often enough before because it requires a large, ongoing user investment with the payoff down the line, some weekend, under duress, when the operator needs the restore. It has to work. Good on you Josh, St.Ack > > On 11/1/17 9:13 PM, Vladimir Rodionov wrote: > >> Pulling B&R off 2.0 release 5-6 weeks in advance (beta1 timeframe)? >> >> I would say that we have enough time to run scalability tests and finish >> doc before beta1 release. >> >> Can we return to this discussion in a 4-5 weeks and then, based on the >> B&R >> state, make a decision? >> >> -Vlad >> >> On Wed, Nov 1, 2017 at 5:57 PM, Sean Busbey <[email protected]> wrote: >> >> Hurm. Operator facing documentation is a blocker, IMHO, on a feature >>> being ready to ship. Incomplete documentation is part of why we're >>> pulling the Spark integration from 2.0. Good documentation takes a >>> large amount of work. The fact that there's no docs in the guide >>> already makes me think this needs more bake time. (I'm presuming I >>> haven't just ended up in the wrong part of the ref guide, please let >>> me know if I have.) >>> >>> Ideally, we'd also have an appendix explaining how things work >>> internally for folks digging in as contributors on the project. But >>> that'd be a nice to have. >>> >>> >>> >>> On Wed, Nov 1, 2017 at 7:39 PM, Vladimir Rodionov >>> <[email protected]> wrote: >>> >>>> Sean >>>> >>>> No, this is not our backup description, it is pre-backup era guideline >>>> >>> how >>> >>>> to do backup in HBase, using snapshots, copy table etc. >>>> >>>> >>>> >>>> On Wed, Nov 1, 2017 at 5:28 PM, Sean Busbey <[email protected]> wrote: >>>> >>>> Vlad, >>>>> >>>>> As someone who hasn't spent much time with the backup/restore feature >>>>> yet, could you help me out on getting a foothold? >>>>> >>>>> Which of these Backup/Restore options is it we're specifically talking >>>>> about: >>>>> >>>>> http://hbase.apache.org/book.html#ops.backup >>>>> >>>>> >>>>> >>>>> On Wed, Nov 1, 2017 at 1:33 PM, Vladimir Rodionov >>>>> <[email protected]> wrote: >>>>> >>>>>> 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. >>>>>>>> >>>>>>> >>>>>> That is not correct. All blockers have been resolved, the last one >>>>>> >>>>> has a >>> >>>> patch which is ready to be commited. >>>>>> >>>>>> Salesforce team has conducted independent testing and found no issues >>>>>> >>>>> with >>>>> >>>>>> a functionality to my best knowledge. >>>>>> >>>>>> Explain please, Stack. >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 1, 2017 at 10:32 AM, Stack <[email protected]> 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). >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> hbase-spark: Purging this makes me tear-up. >>>>>>> >>>>>>> What else? >>>>>>> >>>>>>> Thanks, >>>>>>> St.Ack >>>>>>> >>>>>>> >>>>> >>> >>
