[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rob Savoye
Subject: Re: [Gnash-dev] Definition of "blocker" bug severity
Date: Mon, 20 Dec 2010 09:43:42 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b2 Thunderbird/3.1.7

On 12/20/10 09:28, strk wrote:

> I fixed those before anyone could file a bug, it looks like.
> Or can you find a bug filed for them ?

  Right, as they were blockers, you fixed them right away, so there was
no need for a bug report. :-) You should really learn to test your
changes more thoroughly and this wouldn't happen.

> What's the use of a tracker for something that has to be looked into
> immediately ? The tracker  is there so "we don't forget" about something.
> An urgent breakage should be acted upon by someone having nothing else in
> his mind 

  We use the tracker because we are distributed across many time zones.
Sometimes, unlike the example above, the developer doesn't realize they
broke something. So a "Blocker" email from Bugzilla notifies them they
have a big problem. To me, a Blocker, which breaks builds for everyone
means drop everything else and fix it right away... "Important" is more
like fix it as soon as possible, but don't drop everything else.

 So to me, as the release person, I treat "Important" the same way you
do "Blocker", so the end result is the same. I think I object to Blocker
is because I consider it a very serious thing, so when I get emails with
Blocker in them, I have to decide whether to drop everything I'm working
on and fix it immediately.

  Obscure breakage that effects Debian Lenny only us not an immediate

> You seem to be the author of this wiki page about release management:

  Yep. I had Russ do a few releases when we had the funding for it, so
had to document the process some.

> The second step in your process is "fix critical or Blocker bugs"
> So it looks like you agreed with me at time of writing that one.

  Right, I think in the long run we both agree. :-) Turning this into a
personal issue is kindof a waste of our time... It'd be easier to
discuss things if you focused on the issues instead of attacking me.

> Beside, these organizational things are part of "helping with releases"
> (wiki editing, NEWS editing, testing various combinations, filing _blocker_
> bugs so they don't get unnoticed at release time, ...)

  For the last several releases, I've been the only one to update
documentation, updating files, etc... As I'd like to start the release
in a few weeks, it'd be nice to have somebody go though our docs and
make updates.

        - rob -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]