Version: 0.2 (01/03/2003)
http://yendi.cc.cmu.edu/work/softenv/andrew-bugzilla-use.html
This document outlines Computing Services' use of Bugzilla, both current use and recommendations for the future.
Bugzilla is a web based bug tracking system developed to support the Mozilla project. Details can be found at http://www.mozilla.org/bugs.
Bugzilla objects center around bugs, which are numbered starting at 1. The Andrew bugzilla installation currently has around 1700 bugs, of which about 500 are "open".
The lifecycle of a typical bug moves from "New" to "Assigned" to "Resolved". "New" bugs have just been filed; a bug becomes "assigned" when an engineer (more generally, anyone with an account) has accepted responsibility for it, and becomes "resolved" when the problem has been resolved.
If a bug can't possibly be closed, it isn't a worthwhile bug. This doesn't mean bugs shouldn't be long-lived, or even not resolvable in our current resources, but if a bug just can't be resolved, it becomes permanent clutter and therefore should not exist (and, if filed, should be closed as WONTFIX with a proper explanation).
Bugs have a long discussion trail and several properties associated with them. Bugs are associated with a specific component of a product. They have a version (of the product), a severity (ranging from "feature" to "blocker") and a priority. They have a target milestone.
What about bboard integration with the discussion trail?
For tradiitional development projects, a milestone is normally the future version that a particular bug will be solved by. For bugs that aren't targetted to be resolved by a particular version, a catch-all milestone of "Future" is usually associated with the bug.
Don't close bugs that won't be immediately fixed: closed bugs are harder to search for and generally just drop completely from memory. This also means that one should not resolve a bug with REMIND.
Computing Services has also shown an interest in using Bugzilla for non-traditional uses, such as platform maintaince, Remedy deployment, and internal web applications. So far these alternate uses have not utilized milestones, which is a pity: milestones allow users to determine where to put their effort or what bugs are going to be resolved "soon".
Since these non-traditional uses don't necessarily have formal version numbers, I propose that we use semester boundaries as our milestones. Much of Computing Services effort can be organized along this timeline.
The top level hierarchy of Bugzilla is the "product". All bugs in a product share version numbers and milestones. When we want to add stuff to Bugzilla, two things to keep in mind are:
Environment maintinence and internal applications (much of what the division does) pose interesting problems: since the Unix or Windows environment is never "shipped", what does deliver mean? The obvious answer is "release to gamma" or equivalent; while gamma releases can happen at any time, we generally target large changes to the beginning of a given semester.
What about web applications? Some web applications (components of "my andrew") are grouped together by user view. Others might be grouped to backend systems ("Student Information On-Line" or "Webmail") and might more logically be grouped with that. A generic web application product is probably sufficent for most of the smaller web applications.
Use of Bugzilla forces some amount of workflow on a system. If the workflow isn't aligned along the lines that Bugzilla expects, people are more likely to disregard Bugzilla—making it a less useful tool or even an impedement.
When we use Bugzilla for a project, it should be the canonical worklist for that project. Any problem that isn't immediately solved should be placed into Bugzilla and closed when it is resolved.
Bugzilla can be configured to automatically "nag" people about un-assigned bugs. This might encourage people to at least file comments about bugs that have been newly opened and prioritize them. Managers could be the default owners for many products or components, assigning them to individuals with a milestone and a priority or merely accepting them and marking them low priority.
Software that we develop internally should get version numbers. Bugzilla is well suited to this: milestones can be set to the version numbers or even "v1.2 alpha", "v1.2 beta", "v1.2" if sub-version milestones are desired. The mapping of milestone version to calendar date is kept outside of Bugzilla; it often slips and changing dates in Bugzilla can be more of a nuisance than a help.
Bugs should generally be closed when they are fixed in the canonical source repository. For many of our projects, this is either an AFS volume or a CVS repository.
A seperate component for specific CMU deployment should be created, if deploying the application internally is likely to generate it's own set of problems or dependencies.
if a bug is closed when it is fixed, how do we ensure that it gets released? The CMU deployment component?
Our platforms don't have "versions"
vendor report tracking
mixed mode packages.
Milestones will be prefaced with the semester of the form of Fall, Spring, or Summer. It will then be followed with the year (e.g. 2003).
The milestone is before the semester. For example, a milestone of Fall2003 means the release will be done before the start of the Fall 2003 semester.
There will be a special milestone of Future which indicates that we should deal with it at some point in the future but it is not pressing enough to deal with immediately. If the priority escalates, the milestone should be updated appropriately.
Should mid-semester break, spring break, thanksgiving break also be considered milestone points?
0.2 - 01/03/2003 - wcw - formatting and random text 0.1 - 12/31/2002 - leg - Initial version