hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 张铎(Duo Zhang) <palomino...@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)
Date Fri, 10 Mar 2017 01:48:29 GMT
Let's just cut branch-2 ASAP and set a deadline for the partially-completed
features?

2017-03-10 9:29 GMT+08:00 Mikhail Antonov <antonov@apache.org>:

> >>"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)
> >
>

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