On the original topic - on one hand, the fewer code lines we maintain the better, as less volunteering time and efforts are spent on that. Also does postponing of EOL-ing of older releases slow down adoption of newer releases?
On the other hand, if we believe ITBBL is broken / unreliable for some release this is a bad state to be in. @Andrew - I think this is also a question of what exactly is deemed wrong with ITBLL. What kind of issues do you observe on 1.2? Do you observe data loss (unref / undef keys after Verify run), or does job fail to complete because regions in transition / offline, or is it something else? How reproducible is that for you? Could you share some more details of your experiments (should it be a separate thread, probably?) -Mikhail On Fri, Nov 4, 2016 at 9:57 AM, Andrew Purtell <[email protected]> wrote: > Let me add I'd switch my thinking to +1 for retiring 1.1 if, now that we > have a 1.3.0RC0 shaping up, it turns out the 1.3 code line can survive the > same 1B ITBLL testing that 1.1 does (and 1.2 does not). > > On Fri, Nov 4, 2016 at 9:52 AM, Andrew Purtell <[email protected]> > wrote: > > > I'm -1 on this idea, for now. > > > > We have been evaluating 1.1 and 1.2 for upgrade and whereas 1.1 will > > survive all testing including large scale ITBLL tests, 1.2 will not - no > > 1.2, from 1.2.0 on up. I've found one issue (fixed), and am now trying to > > nail down another. > > > > I would like to see two things: > > > > 1. Others in the community step up to evaluate the stability of 1.1.7 > > versus 1.2.3 (or .4) using ITBLL with at least 1B rows of data, and > report > > in. Is it just me? > > > > 2. We do not declare 1.1 EOL until 1.2 is unquestionable stable according > > to the most practical rigor we can throw at it with our tooling. > Especially > > because I still plan to resign as 0.98 RM soon, which I think will > trigger > > an EOL of that code line. > > > > I will be resigning as 0.98 RM effective January 1 2017 and at that time > > the community can discuss what to do with 0.98. From my point of view, > I'm > > done with spending time on it. Happy to take some of the time freed up > and > > use it to carry 1.1 forward if we are still making releases off this code > > line then. > > > > > > On Fri, Nov 4, 2016 at 9:24 AM, Nick Dimiduk <[email protected]> > wrote: > > > >> Hello HBase Community! > >> > >> We have a small matter to discuss. > >> > >> HBase 1.2 has been formally marked as "stable" for the last couple > months. > >> HBase 1.3.0rc0 is just around the corner. I think it's time to start a > >> conversation about retiring the 1.1 line. The volunteer bandwidth for > >> maintaining multiple branches is precious and as we spread ourselves > more > >> thin, odds of decay increase. > >> > >> I propose discontinuing 1.1 with a single release following 1.3.1. > That'll > >> give us one last chance to back port any bug fixes discovered in the > >> diligence we're putting into the new minor release. Given the current > pace > >> of 1.3, I estimate this will happen in January or February of 2017. It's > >> not a lot of time for existing deployments to get around to upgrading, > but > >> the upgrade path is trivial and 1.2 has been available for quite some > >> time. This will probably make our last release from this branch at > 1.1.10 > >> or there abouts. > >> > >> Are there any objections or concerns with the above plan? Are there any > >> downstream communities who need our help moving onto 1.2? Please let us > >> know. > >> > >> Thanks, > >> Nick > >> > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > -- Thanks, Michael Antonov
