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 <[EMAIL PROTECTED]> 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 > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel