hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
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)
Date Thu, 09 Mar 2017 19:25:28 GMT
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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message