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: <CAPQQKxem3OovpjyDYBL9XFbtWiToWAzxDoRPb7Uu=kDvqT9qHg@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>
 <CA+C_EDhK6EA7MyVAQj7-i17JD5njKwpSyU-geJsmjbxGcq7F2w@mail.gmail.com> <CAPQQKxem3OovpjyDYBL9XFbtWiToWAzxDoRPb7Uu=kDvqT9qHg@mail.gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Thu, 9 Mar 2017 13:52:04 -0800
Message-ID: <CA+RK=_ATNuDMRQ8F92PD+4Licnpv5-EgQO8HQe9QDzZzLE=HxQ@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" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a113cacbce44af3054a534350
archived-at: Thu, 09 Mar 2017 21:52:49 -0000

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

Oh, I don't know. I may never be comfortable with a backport of MOB into
branch-1, but a branch-2 including it would be fine.

And my point is not that making a branch-2 out of branch-1 is desirable,
simply that it could be the most practical way forward if we are stuck on
master with too much unfinished work that cannot be reverted in order to
make a production ready release.


On Thu, Mar 9, 2017 at 1:12 PM, Stephen Jiang <syuanjiangdev@gmail.com>
wrote:

> I don't see a point to have branch-2 from branch-1.  For customer/users, we
> always can have a 1.x release to give them all the features they want from
> branch-1.
>
> My understand is that one of the difference of major release and minor
> release is that major release could break some backward compatibility.  If
> any features that in master, but not in branch-1, as long as not breaking
> backward compatible, the owner of the feature always can back-port to
> branch-1 if they desire.  Today we don't have voting process to block that.
>
> For 2.0 release or future major release, what we need is planning - THEME
> (what is the biggest excitement for the release) and MUST-HAVE FEATURES.
> All must-have features should have an owner and some estimate of completing
> time.  Once the consensus is reached, then next step is execution - the
> release time would be based on progress of these must-have features.
>
> Thanks
> Stephen
>
> On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <ashu210890@gmail.com>
> wrote:
>
> > 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
> >
>


-- 
Best regards,

   - Andy

If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)

--001a113cacbce44af3054a534350--