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

Collapse
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 (major.minor.dot), 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.