hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Helmling <ghelml...@gmail.com>
Subject Re: putting a border around 0.92 release
Date Wed, 02 Mar 2011 23:46:48 GMT
I think it's very relevant that the linux kernel moved from one approach to
the other as it reached a certain scale of developer participation and
broader ecosystem support.  I think what really enables the "new linux"
approach is the fact that there are multiple layers of stabilization between
the kernel.org releases and what the average end user actually runs (a
stable vintage maintainer, distributor kernel teams, distributions with
their own stable and more frequent releases).  This is really well
articulated in the Linus interview sent around (thanks for the link Todd!).

I think it's great that Cloudera is starting to play this role for HBase.
 And I expect we'll continue to see the ecosystem expand.  But many people
run the Apache releases and I would hate to add any confusion to which
release people should download and run.  (We already have Hadoop
contributing enough confusion there).

IMO, we're also not yet at the scale of developer participation where we
have lots of free cycles to volunteer to maintain a specific "stable"
release.  I certainly feel too busy for it, and the rest of you all seem
even busier than me!

I do believe we should timebox our releases to have a predictable schedule
and punt features if they're not ready.  Maybe that alone produces enough
friction against the pain of upgrading large-scale, long running clusters
that "stable vintages" will start to seem worthwhile, but I'm not totally
convinced yet.  Let's get some iterative release rhythm going first.

To this end, I think full read/write git support from ASF infra would help a
lot.  It would close the loop on more easily handling feature-branch
development.  Github goes a long way, but that last bit of: apply patch to
svn, then remerge back to git is sometimes annoying.  Anyone know of any
more progress on this: https://issues.apache.org/jira/browse/INFRA-3165 ?

So my vote is to do odd-even stable for now.  But let's get to the point
where we're iterating frequently enough and have grown enough hands that the
"stable vintages" becomes a better alternative and we can drop the odd
releases completely.

Can we set a goal of targeting a 0.92 release date at the hackathon (or at
least RC target date)?

--gh


On Wed, Mar 2, 2011 at 2:50 PM, Todd Lipcon <todd@cloudera.com> wrote:

> On Wed, Mar 2, 2011 at 2:44 PM, Andrew Purtell <apurtell@yahoo.com> wrote:
> > My vote is odd-even stable.
> >
> > I don't like the idea of vintages. We have this situation internally, a
> release based on 0.20.6 that I won't be able to kill fast enough now that we
> have something based on 0.90.0. If I needed to support the 0.20 "vintage"
> I'd have someone working full time on making 0.90.0 API and RPC compatible
> with 0.20.6 and upgradeable via rolling restart. A total nightmare.
>
> Of course vintages get killed off after a certain time. Also, to a
> certain extent this becomes the job of distributors. For example,
> Cloudera will be supporting 0.90.1 (or something that's 100%
> compatible with it) for at least the next year, regardless of how
> whiz-bang 0.92 or future releases will be.
>
> -Todd
>
> >
> > --- On Wed, 3/2/11, Todd Lipcon <todd@cloudera.com> wrote:
> >
> >> From: Todd Lipcon <todd@cloudera.com>
> >> Subject: Re: putting a border around 0.92 release
> >> To: dev@hbase.apache.org
> >> Cc: "Jean-Daniel Cryans" <jdcryans@apache.org>
> >> Date: Wednesday, March 2, 2011, 2:39 PM
> >> On Tue, Mar 1, 2011 at 9:34 AM,
> >> Jean-Daniel Cryans <jdcryans@apache.org>
> >> wrote:
> >> >
> >> > That's a pretty good interview, thanks for sharing!
> >> Soooo is our idea
> >> > of using odd numbered release as DRs bad? Should we
> >> just release more
> >> > often like every 3 months? I vote Stack as our Linus!
> >>
> >> I think there are basically two ways of going about this,
> >> and it
> >> depends on a philosophical choice:
> >>
> >> The old Linux way (odd-even stable):
> >> - users knew that 2.3.x and 2.5.x were development series
> >> and wouldn't
> >> be stable.
> >> - distros and almost every user ran off even-numbered
> >> releases
> >> - odd-number releases might be fairly broken
> >> - there's some pre-release decision that the release will
> >> be an
> >> even-numbered "stable"/"good" release as opposed to a
> >> odd-numbered
> >> dev-quality release.
> >>
> >> This is basically what we did for 0.89.x. I thought it
> >> worked fairly well.
> >>
> >>
> >> The new Linux way ("good vintages and long-lived
> >> branches"):
> >> - new releases are done time-based and there's no guarantee
> >> of any
> >> particular stability level
> >> - users rely on some documentation somewhere to know what a
> >> "good vintage" is
> >> - either distributors or some section of the community
> >> steps up to
> >> designate some good vintage to be a long-lived branch,
> >> where critical
> >> bugfixes will get backported. eg 2.6.18 was a good vintage,
> >> 2.6.32 is
> >> another.
> >> - the "good vintages" aren't decided at release-time, but
> >> rather
> >> retroactively - ie we just release on the train model, and
> >> at some
> >> point someone takes one of those trains that "seems pretty
> >> good" and
> >> starts stabilizing it up.
> >>
> >> The interesting thing about the "good vintages" model is
> >> that you
> >> don't follow the usual policy of a bugfix having to be
> >> backported to
> >> all releases in between trunk and the vintage. Let's
> >> pretend we had
> >> 0.90, 0.91, 0.92, 0.93, and 0.94, where 0.90 was the "good
> >> vintage"
> >> release. If we commit a fix to trunk in today's Apache
> >> model, we'd
> >> also have to commit to ALL of those releases back through
> >> 0.90, which
> >> is a giant pain.
> >>
> >> The other interesting (and more philosophical) bit is that
> >> the "good
> >> vintage" model serves to separate the developers from the
> >> users, in
> >> that the users are expected to be several releases back on
> >> a stable
> >> branch. This can be both good and bad - bad because it
> >> takes a while
> >> for a new feature to trickle to a user, good because
> >> changes go
> >> through a few layers of vetting for bugs before they hit
> >> users.
> >>
> >> Any thoughts?
> >>
> >> -Todd
> >> --
> >> Todd Lipcon
> >> Software Engineer, Cloudera
> >>
> >
> >
> >
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

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