hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Antonov <anto...@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 01:29:12 GMT
>>"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