Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <CA+RK=_AqQrVpMfRsLrBMorZoWnFBhsfT9oZniE-89276U-6cBw@mail.gmail.com>
References: <CANZa=Gu-=d_4PGtH6sUfjzM31uQT_Zr1k4-LetEAWq_CfaYk+A@mail.gmail.com>
 <CA+RK=_Asna9NUAhh7OSrrvyafAw30RGNyhTZcmG+7W-u8Q5p+A@mail.gmail.com> <CA+RK=_AqQrVpMfRsLrBMorZoWnFBhsfT9oZniE-89276U-6cBw@mail.gmail.com>
From: Mikhail Antonov <olorinbant@gmail.com>
Date: Fri, 4 Nov 2016 14:31:52 -0700
Message-ID: <CAHxLZBV3-EBe8PPhyDXSeVbdSA6D0NvvmX9JemtGLKiSFo45Cg@mail.gmail.com>
Subject: Re: [DISCUSS] EOL 1.1 Release Branch
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Cc: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a113f8042d7bcbb0540806867
archived-at: Fri, 04 Nov 2016 21:32:34 -0000

--001a113f8042d7bcbb0540806867
Content-Type: text/plain; charset=UTF-8

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 <apurtell@apache.org> 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 <apurtell@apache.org>
> 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 <ndimiduk@apache.org>
> 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

--001a113f8042d7bcbb0540806867--