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=_ATNuDMRQ8F92PD+4Licnpv5-EgQO8HQe9QDzZzLE=HxQ@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> <CA+RK=_ATNuDMRQ8F92PD+4Licnpv5-EgQO8HQe9QDzZzLE=HxQ@mail.gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Thu, 9 Mar 2017 13:57:58 -0800
Message-ID: <CA+RK=_Bhg9TyNcEf7As69YZQitOJoEkHFVnigTEEcCaueKWK-Q@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=001a1140eab4feb40d054a5358ac
archived-at: Thu, 09 Mar 2017 21:58:43 -0000

--001a1140eab4feb40d054a5358ac
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> For 2.0 release or future major release, what we need is planning - THEME
=E2=80=8B> =E2=80=8B
(what is the biggest excitement for the release) and MUST-HAVE FEATURES.
=E2=80=8B> =E2=80=8B
All must-have features should have an owner and some estimate of completing
=E2=80=8B> =E2=80=8B
time.

=E2=80=8BWith all due respect, this is just talk. Appeals to planning and "=
must
have" features has an import that decays proportionally to the time since
the last time we had some words about it. 2.0 keeps slipping, slipping,
slipping. The PMC needs to come to terms with the actual amount of
development bandwidth we have available and set a cut point. Make it
happen, "do-ocracy" style. =E2=80=8B


On Thu, Mar 9, 2017 at 1:52 PM, Andrew Purtell <apurtell@apache.org> wrote:

> 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 fr=
om
>> 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 breakin=
g
>> 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 - THEM=
E
>> (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 bran=
ch
>> > 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 workin=
g
>> > > 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 commi=
t
>> --
>> > > > witness how long it took us to get to a 1.0 -- and then pushing ou=
t
>> 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)
>


--=20
Best regards,

   - Andy

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

--001a1140eab4feb40d054a5358ac--