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=_CkmyVsKyLTgiSKy5H+UUM22P4w=PA30k8srfq14_RjBg@mail.gmail.com>
References: <CA+7gEcjmp3gccX3TZikQQ3O7_mJbb68TMUTn-Jubcv_NoYHjfQ@mail.gmail.com>
 <CADcMMgG8_bRe1e__hqk-UUrLLAne-5Bi7wFSshZ+SoQgq5WgTA@mail.gmail.com> <CA+RK=_CkmyVsKyLTgiSKy5H+UUM22P4w=PA30k8srfq14_RjBg@mail.gmail.com>
From: Ashu Pachauri <ashu210890@gmail.com>
Date: Thu, 9 Mar 2017 11:53:50 -0800
Message-ID: <CA+C_EDhK6EA7MyVAQj7-i17JD5njKwpSyU-geJsmjbxGcq7F2w@mail.gmail.com>
Subject: Re: A suggestion for releasing major versions faster (Was: NOTICE:
 Nice testimony on benefits of the offheap read-path work now up on our blog)
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=f403045fb1a8a302fd054a519a67
archived-at: Thu, 09 Mar 2017 20:00:48 -0000

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

In my opinion, a major release is based on two simultaneous decisions:

1. Is it time; may be a year is a good time frame? (It's useless
accumulating too much code that is not battle tested and then expect people
to deploy it to production without experiencing a plethora of issues.)

2. Is there at least one "major feature" that is complete ?

I think if we can answer yes to both these questions at any point in time,
it's a good idea to cut the RC and ask people to start testing it.

the only way forward for saving 2.0 at this point is to *make the branch and
> spin the RC

+1


On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <apurtell@apache.org> wrote:

> The only way forward for saving 2.0 at this point is to *make the branch
> and spin the RC. *Just do it. Kick out by revert what obviously isn't
> ready. Solicit help in getting partially finished things into working
> state. Kick them out too if the help does not arrive.
>
> Maybe too much is in a half done state and the scale of effort for those
> reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 from
> branch-1 and backport a select number of things from master into the new
> branch-2. Then release. I do a variation of this for the $dayjob so would
> be your man to turn to for driving this if that's the way forward.
>
> I know it's easy to recommend the labor of others. Depending on what we are
> going to do I can talk to work about freeing up time to help.
>
>
> On Thu, Mar 9, 2017 at 11:18 AM, Stack <stack@duboce.net> wrote:
>
> > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <yangzhe1991@apache.org>
> wrote:
> > >
> > >
> > > So my suggestion is cutting branch-x faster and have some fixed period,
> > for
> > > example, six month or one year?
> > >
> >
> >
> > You are right Phil.
> >
> > The Release Managers for the minor releases have been doing a good job
> > keeping up a decent release cadence but we have an abysmal track record
> > when it comes to pushing out majors. First we were afraid to commit --
> > witness how long it took us to get to a 1.0 -- and then pushing out the
> 1.0
> > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. My
> > sense is that 2.0 is beyond saving at this stage.
> >
> > Can we do 3.0 different? As per your suggestion?
> >
> > St.Ack
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>


-- 
Thanks and Regards,
Ashu Pachauri

--f403045fb1a8a302fd054a519a67--