On 9/12/06, Jim Fulton <[EMAIL PROTECTED]> wrote:
FWIW, I use the following approach:
- Early in the process, I mark every real reproducable bug as blocking.
In this last go around, this included a number of bugs that had been
around for months or years.
- Later in the process I downgraded lots of bugs because I didn't
want to block the release.
Ah. Well, that procedure definitely can get improved on. :)
I think it is imperative that we mark bugs according to the
seriousness so that you know which bug should be worked on first.
I note that the Zope3 collector has the categories medium, low,
critical, 3.3 release and 3.4 alpha 1. I don't think that's a good
idea, but I understand that the Zope collector has no field for
planned release, and those options make sense for features. :-)
Anyway, for me it's like this:
A blocking/critical bug is a bug that means the system or part of the
system gets unusable. It has no workarounds, and affects most users of
the system. Say, PUT_factory suddenly stops working, meaning that FTP
and WebDAV no longer works.
A serious/medium bug is a bug that is a big problem for many users and
has no workaround, or affects everybody, but has a workaround. For
example, that XML import/export didn't work: Workaround, use the non
A minor bug is a bug that affects few users and has a workaround, or
has no workaround but only is a problem in very extreme edge
usercases. For example...euhm, ehhh, I can't think of one right now.
(and a trivial bug is not an actual problem for anybody. Could be
spelling errors or ugly design.)
A bug should be assigned a category and stay there. It should not get
it's category changed so not block a release, because if you can do
that, well, then it wasn't blocking in the first case.
Zope3-dev mailing list