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

[Greg Smith]

Hi Scott,

Good catch. We did talk about the question of marking bugs. Sorry I 
missed that in my notes.

I think it was agreed that we talk about those in the weekly software 
status meeting. Also, that bugs which are considered blockers should 
have the keyword: blocks:8.2.0

This is documented along with the current agreement on bug tagging in 
general on the Trac home page: http://dev.laptop.org/ conventions section.

My thinking is that new features and functionality are tracked via: 
http://dev.laptop.org/report/18

Problems with existing features which don't work as they did in previous 
releases or don't work according to documentation are flagged as 
critical items for resolution by keyword: blocks:8.2.0

Let me know if you that plan doesn't work for you.

Thanks,

Greg S

C. Scott Ananian wrote:
> 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
>