FAQ
To date (or at least in the past 1.5 years I've been working on
Hadoop), our shortest timeline from feature freeze to a release vote
has been around 4 weeks. This time is typically spent fixing blockers.

I'd like to propose that we tighten up on what a blocker is, get the
release out sooner, and then plan to do follow-on bug fix releases on
a regular interval. As your release manager, I'll sign up to
consider a bug fix release every 2 weeks if there is a critical
enough bug or a critical mass of bugs. Roughly every 2 weeks, then,
would be a window to consider a bug fix release.

For 0.16.0, can we set a goal of having all blocker committed and
calling a vote next Thursday, Jan 24, with a blocker defined as
a) a bad regression
b) an unintended incompatibility
c) bad bugs in an important new feature

Thoughts?

Nige

PS As a reminder, 0.17.0 is scheduled for the first Friday in April
(3 months).

PPS Monday, Jan 21 is a holiday in the US for many companies

Search Discussions

  • Doug Cutting at Jan 17, 2008 at 8:52 pm

    Nigel Daley wrote:
    For 0.16.0, can we set a goal of having all blocker committed and
    calling a vote next Thursday, Jan 24, with a blocker defined as
    a) a bad regression
    b) an unintended incompatibility
    In particular, things that cause programs which worked in prior releases
    to no longer function in fundamental ways and with no easy workaround.
    c) bad bugs in an important new feature
    I don't think these should generally be blockers. New features may be
    buggy in their first release. Hopefully they'll be less buggy in
    subsequent releases, but I don't think bugs in new features should block
    a release from going out. That said, I'm okay making a bugfix release
    that doesn't contain any blockers. We should generally refuse to merge
    new features and improvements to a branch, but bugfixes deemed safe,
    whether regressions or to new features, can be included in a bugfix
    release. Does that sense?

    Doug
  • Raghu Angadi at Jan 17, 2008 at 11:34 pm
    What is the difference between current blocker definition and one
    defined here?

    Raghu.

    Nigel Daley wrote:
    To date (or at least in the past 1.5 years I've been working on Hadoop),
    our shortest timeline from feature freeze to a release vote has been
    around 4 weeks. This time is typically spent fixing blockers.

    I'd like to propose that we tighten up on what a blocker is, get the
    release out sooner, and then plan to do follow-on bug fix releases on a
    regular interval. As your release manager, I'll sign up to consider a
    bug fix release every 2 weeks if there is a critical enough bug or a
    critical mass of bugs. Roughly every 2 weeks, then, would be a window
    to consider a bug fix release.

    For 0.16.0, can we set a goal of having all blocker committed and
    calling a vote next Thursday, Jan 24, with a blocker defined as
    a) a bad regression
    b) an unintended incompatibility
    c) bad bugs in an important new feature

    Thoughts?

    Nige

    PS As a reminder, 0.17.0 is scheduled for the first Friday in April (3
    months).

    PPS Monday, Jan 21 is a holiday in the US for many companies

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcommon-dev @
categorieshadoop
postedJan 17, '08 at 5:08p
activeJan 17, '08 at 11:34p
posts3
users3
websitehadoop.apache.org...
irc#hadoop

People

Translate

site design / logo © 2022 Grokbase