Release Status Meeting - 8.2.0 - Tomorrow, 2:00 PM EDT, various venues - Notes

[C. Scott Ananian]

On Tue, Jul 1, 2008 at 5:13 PM, Greg Smith <gregsmitholpc at gmail.com> wrote:
> We talked about what this page offers that we don't already have. The
> conclusion was that its a high level view of the main features in the
> release. Each item on this page should include a list of relevant bug id
> that give the next level of granularity.
>
> Greg asked if this is too much process and no one said it was, definitively.

I also expressed concern that this view of the process doesn't include
an explicit means for tracking blocking bugs and regressions.  I think
the idea was generally accepted that a feature-driven list like this
is most useful early in the release cycle and at "decision times" when
decisions to cut features have to be made, but that later in the
process features are expected to be "done" and the most important
release driver is "blocking bugs".

(Now switching back to expressing personal opinion:)
For the moment, I'm personally concerned with "how close are we right
now to release" which (to me) means, "how many blocking bugs and
regressions are left in joyride". Taking the extreme view, I don't
care how many features are complete in it -- I'm perfectly willing to
cut some features if that's the shortest path to fixing a bug and
getting "most of the features" out on time.  (Unfortunately, many of
our current blocking bugs are caused by big already-landed features in
a way that would be more work to back out the feature as it is to
simply fix the bug.)

Maybe I'm premature in switching to a blocker-oriented view, but I
certainly want to ensure that we don't lose sight of the big bugs as
we congratulate ourselves on landing or partially-landing features.
IMO we made the "feature view" decisions several weeks ago, when we
(among other things) committed to basing 8.2 on F9.  Now that we've
done so, the blocker view deserves to be foregrounded to drive the
bugs out.
 --scott

-- 
 ( http://cscott.net/ )