hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Yang <yangzhe1...@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 Fri, 10 Mar 2017 03:54:07 GMT
> To rephrase myself - I think we shouldn't be taking stance that
> MajorBranchX can't be released until features f1, f2, f2,...fN are all
completed.

Agree, we should not be blocked by any feature.

Some new features don't conflict with current codes, I think we can just
commit to branches and
add a how-to-enable document into HBaseBook/ReleaseNote or enable it by
default, when it is ready.

For the issues that may break the branch to can-not-release state, I think
we should never get them in and open a feature branch,
merge them when they are all ready.

Thanks,
Phil


2017-03-10 9:41 GMT+08:00 Mikhail Antonov <olorinbant@gmail.com>:

> To rephrase myself - I think we shouldn't be taking stance that
> MajorBranchX can't be released until features f1, f2, f2,...fN are all
> completed.
>
> That's just not going to fly. There will always be features suddenly way
> more complicated than they appeared, features that don't have enough
> manpower behind them, features that are found to be less important then
> they were thought to be.
>
> Instead we probably should say "branch-2 is being cut; (or, in kernel
> parlance, here's merge window dates) whatever didn't make their way into it
> will have a chance to go to branch-2.1, branch-2.2, branch-3".
>
>
>
> On Thu, Mar 9, 2017 at 5:29 PM, Mikhail Antonov <antonov@apache.org>
> wrote:
>
> > >>"The only way forward for saving 2.0 at this point is to *make the
> > branch
> > and spin the RC."
> >
> > big +1 to that.
> >
> > I do also think that talking about planning in the context of open-source
> > community development is a bit hard - there's no planning but what people
> > do. If we release regularly, however, we would naturally be picking
> > important things (features, fixes, optimizations), because things that
> were
> > planned but not completed up to some usable checkpoint state were, by the
> > very definition, not truly important enough in the grand schema of
> things.
> > From the perspective, releasing regularly is more important than
> preparing
> > a list of must-have things and waiting to cross the last work item out
> > before the release can be made.
> >
> > That does pose a problem of partially-completed features. Two viable ways
> > to deal with them that I see are a) use feature branches more and b)
> don't
> > release off master (or, commit new code to some 'unstable' branch first,
> > then pull to master).
> >
> > Thoughts?
> >
> > -Mikhail
> >
> > On Thu, Mar 9, 2017 at 1:57 PM, Andrew Purtell <apurtell@apache.org>
> > wrote:
> >
> >> > 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.
> >>
> >> ​With 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. ​
> >>
> >>
> >>
> >> 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
> >> 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)
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >>    - Andy
> >>
> >> If you are given a choice, you believe you have acted freely. - Raymond
> >> Teller (via Peter Watts)
> >>
> >
> >
>
>
> --
> Thanks,
> Michael Antonov
>

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