Re: naming severities more correctly? [was Re: What if "blocker" meant "blocker"?]

[Elijah Newren <newren gmail com>]

On 1/9/06, Federico Mena Quintero <federico ximian com> wrote:
> On Sat, 2006-01-07 at 18:54 -0500, Luis Villa wrote:
>
> > I'll probably add my two cents to the rest of this thread later (and
> > really bugmaster and/or bugsquad should be cc'd), but we might want to
> > consider renaming the 'blocker' severity to 'development blocker' or
> > something like that, to make it more clear what the field actually
> > represents.
>
> That's a nice idea.  In GTK+ we have a convention for the "Milestone"
> field.  Assumming that the current stable release is 2.8.x, we have
> milestones like these:
>
> "2.10 API freeze" - if this goes in, it must go in before API freeze.
> This of course applies to new APIs.
>
> "2.10 freeze" - new non-API feature, or major non-API bug that must be
> fixed before the next release.
>
> So, would we have "development blocker" for must-have APIs or "this
> proposed API is fucked and must be fixed", and "user blocker" for major
> user-visible bugs or something like that?

I think those are great uses of the target milestone field (which is
different than the gnome target field, just to be clear).  Note,
though, that those are specific to a project (as the target milestone
is supposed to be), and is stuff that really need not be monitored at
a release team or bugsquad level.  However... maybe I'm being a little
dense but I'm not quite sure how the gtk+ target milestones are
related to the rest of this thread.  Could you clarify for me?

> ... Could someone build a list of the current blockers?  We can put out
> a call for volunteers to test those bugs for reproducibility.

I asked Ryan and he started to do so.  Also note that
http://live.gnome.org/ReleasePlanning has links to the potential
blocker lists (the lists depend upon someone setting the gnome-target
field for the appropriate bug in bugzilla) for both the 2.12.x and
2.14.x series, to make it easier for us to find and review them.

Cheers,
Elijah