Re: [Gnash-dev] Definition of "blocker" bug severity

[Rob Savoye]

On 12/20/10 10:13, strk wrote:
> On Mon, Dec 20, 2010 at 10:00:20AM -0700, Rob Savoye wrote:

> Important is something users will be pretty disappointed about.
> Critical doesn't let you develop (say: can't build or crashes at startup)

  But that would be a Blocker then... I think adding a Critical field is
unnecessary. My definition of Blocker matches your definition of Critical.

> 1. Wish
> 2. Minor
> 3. Normal
> 4. Important
> 5. Blocker (release blocker)
> 6. Security (memory error)

  Security is more than a memory error, it's something that somebody
could use to gain access to the system, like they do with Adobe all the
time...

> 7. Critical (can't contribute anymore w/out being fixed)

  All bugs marked Important *should* be fixed for a release. All bugs
marked Blocker need to be fixed immediately. Although I believe the
Important field is just fine, maybe instead if Critical we add a field
called "Release", which would have your definition of "must be fixed
before release". In a sense, a Release tag would cover both our issues.

  All I ask is to not abuse the severity rating. Most all bugs should be
"Normal" or maybe "Important", not Blocker. Because of our difference of
definitions, most of the bugs you've filed are blockers. These should
then be tagged Release or Important instead.

  Now here's the fun part where you get to call me a dictator again. As
the official release person, it would be up to me whether a bug should
truly be tagged Release. It would also be up to me to change bug
severity from Release to something else. If you can't agree to this,
we're gonna fight all the way through the release next month, and I
don't really feel like the distraction... I've worked on several
professional release teams, including the GNU toolchain one, for many
years, and this is how it works. The release team (or person in our
case) always has the final say on what has to be fixed for a release,
cause doing the release is their responsibility.

  The other thing is a bug tagged for the Release should usually be
assigned to somebody else, it's not up to the release person to fix all
the bugs by themself. Doing a release is primarily testing... although
Buildbot will help with that in it's usual annoying way. :-)

  Speaking of the release, I was considering a code freeze, 2nd or 3rd
week of Jan, after I get back from the Ouray Ice Fest. I'll be out
climbing, and mostly offline earlier in the month.

        - rob -