Forum OpenACS Q&A: Re: Proposed post-5.0 changes to openacs bug system

Posted by Eduardo Pérez on
<blockquote> Severity
Severity indicates how badly the system is broken if the bug
isn't fixed. Severity should be set by the reporter.
Currently we have six values for severity:

    1. - Critical
    2. - Major
    3. - Normal
    4. - Minor
    5. - Trivial
    6. - Enhancement

As these are equivalent to bugzilla Severity field:
I take the same definitions.

Have you spoken with bugzilla people about this change?
They may have tried to do the same (and maybe found the change to be an error)

As bugzilla works very good we should follow bugzilla unless we know for sure the change won't be a problem.

I'm saying this because bugzilla seems to have much more installed base and both are GPL.

Posted by Tilmann Singer on
It would also be useful to have a field to record the database version, if that is technically possible.
Posted by Joel Aufrecht on
I've used the smaller list of severities in a number of commercial products with good success, and I don't really see them being used effectively in bugzilla. There are three changes in bugzilla's list and my proposal. The first is basically to eliminate 4 - Minor. What's the difference, exactly, "This is the run of the mill bug." and "Minor loss of function, or other problem where an easy workaround is present." To my mind, nothing. Second is to cut blocker - "blocking" is an attribute of priority, not severity. A trivial spelling mistake, if prominent enough, can be a blocking bug. It's high-priority, but it's not high-severity. Third is to drop Enhancement because we store it in a different field - Bug vs Task.

I would also like to start a discussion about priorities and releases. There are several "things" associated with releases and I want to clarify which are fundamental definitive things and which are dependent. For example, what defines a dot release, the smallest release possible (, from a cvs tag or just a particular date in the tree? I think the basic definition is that any release, down to a dot release, is part of a tested upgrade path. One part of the definition of a major release might be that we break some backwards compatibility.

Then, what are dependent attributes of a release? A tarball is dependent - we cut a tarball when we do a release, rather than releasing when we cut a tarball. Updating docs is another. The full list of these dependent things is probably the Milestone criteria That is to say, when we hit definition X - maybe just the need to release a new feature that's ready and fully backwards compatible, it's time for a dot-release. Once it's time for a dot-release, we have to do everything on the milestone criteria to complete the dot release. Is there anything on that list that should instead be a definitive thing?

Finally, how does this relate to Priority? Priority is a balance between Severity, urgency, cost, and (frequently volunteer, unpredictable) resources. Should we define priority solely in terms of releases? In that case we might have:

  • Pri 0: fix immediately. Used for things that break HEAD or security patches.
  • Pri 1: must fix before next dot release. Even if the dot release is unrelated, these are the most serious bugs that accumulate and should be fixes quickly.
  • Pri 2: must fix before next minor release, should fix before next dot release.
  • Pri 3: try to fix sooner or later.