There are a number of problems with using bug tracking systems that seem to occur regardless of which system is used. Some of these annoyances are discussed in this section.
Most of a bug's information has simple values: a string of text to describe the problem, the name (chosen from a list) of one person assigned to the bug, and so on. If a field holds only one value at a time, things are simple. Everything becomes more complicated when one field can have multiple values at the same time.
A good example of this is the field in a bug that is typically named something like Product, which is used to indicate which of a project's products are affected by the bug. A sensible default value for this field might be All, since that may well be true. However, when the bug affects just a few of the products, the obvious thing to do is to have the field contain multiple values. This could be a string with comma-delimited values, or it could be the input from an HTML form. Regardless of how the information is actually stored, the problem is that the number of choices that can be made in reports and other queries has just increased dramatically.
For instance, if there is a version of the product for Windows, GNU/Linux, and Macintosh, and bugs may affect one, two, or all three of these versions, then your reports show some subset of these choices. When another version for the next version of Windows is added, all the reports become out-of-date, because ...