User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020623 Debian/1.2.5-0.woody.1 Build Identifier: This is something that Oracle has had in their bug database for a while now. Bugs that you can pull up on their support site will have some fields that look something like this (made-up data, *emphasis* => italics in the HTML, and all this is off the top of my head): Versions *believed* to be affected: All versions >= 8.1.6.0 but < 10.0.1.0 Versions *confirmed* as being affected: 9.0.1.4, 9.2.0.3 Versions *confirmed* as not being affected/fixed: 7.3.4, 8.0.6, 8.1.5, 9.2.0.4, 10.0.1.0 I'm actually not sure about whether Oracle does that last line in that fashion, but I know the first two lines are what they've done routinely. I hear that an upcoming release of Debian's Bug Tracking System (BTS) will sport something at least vaguely similar. Currently Bugzilla and most other BTSs I'm aware of only let you specify one version that's affected, and that's it. This was a great help when I was doing Oracle work full-time and referred to their bug database frequently (infer what you like from that statement...), and I think it would be a great addition to Bugzilla. A similar approach might also benefit the OS/platform selection situation, but that's best discussed in bug 12309. Reproducible: Always Steps to Reproduce:

OK, I'll bite. This would be useful, but just a text box would be pretty lame. Any ideas how to make it a bit more understandable?

For presentation, I think the format originally specified is workable. For Web input, though, I don't have any strong suggestions. I never had direct access to author such reports on Oracle's system, so I don't know how they did it. :) In fact, the notes were published as notes, not directly in their BTS. The notes that were published like this followed an obvious template, but for all I know they were authored by hand by somebody who looked through the relevant bug reports in the BTS. If that's the case, we'd be the pioneers in trying to automate it (though I do strongly suspect there were some tools behind-the-scenes to do much of the work for them). My first reaction was a Web form with a table of "recent" product versions (and perhaps a "full" form to go back in time some more), with checkboxes or drop-down boxes or something for each version. For fast-moving packages in a Linux distro, say, the resulting form would be quite large and ugly, and for a contiguous range of versions, it would result in a lot of clicking of checkboxes. Ick. A variant of that would be two or more listboxes, which would allow for {control,shift}-clicking. Better, but maybe not perfect. Next thought is using dropdowns with the list of versions, and an entry for "starts with" and "ends with" (corresponding to the ">=" and "<" in the output text). Ranges are much more logical to enter that way. Having multiple ranges would require multiple lines, and a "More" button to click to expand the form. (While this is a common idiom, if you have absolutely no idea what I'm on about there, go to teoma.com and do an advanced search; note the "Add an Entry" and "Delete an Entry" buttons.) This might or might not be pleasant if individual versions are at issue--yes, they're equivalent to degenerate ranges where the start and end points are equal, but still. Control-clicking a listbox is looking nice after all. Plug into all that the possibility of buttons to act as macros for certain subsets of versions ("all 2.4.x versions"). Those would be administrator-created and not automatically derived from the version list, I would think, since there's no useful way to determine what sets of versions are meaningful as a group. Oh, and then there's the task of editing the bug afterwards... If those ideas are all too ugly, I hope somebody will jump in with better ones. I'm a database guy much more than I am a Web guy. (On that note, I'm torn between storing the range endpoints in a child table, one row per range, and enumerating the individual versions in a child table, one row per version. I don't believe the database scheme should necessarily be the same as the UI scheme.) Don't forget, Debian is deploying something kinda like this. I hear they're probably waiting for sarge to release to go live, so whenever that happens, we might have a working example to copy.

Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.

*** This bug has been marked as a duplicate of 287326 ***

I'm curious, how is this a duplicate of bug 287326?

I could see where this depends on: bug 287330 "Ability to add custom multi-select fields to a bug" but not a dup of the single-select field. And I say depends on, because this bug would still want to have a way to keep the options in each of the 3 fields in sync as they would presumeably all have the same set of versions.

I'd also be interested in this enhancement, but can't see any way that it is a duplicate of bug 287326. Reopening. Perhaps it could be a duplicate of bug 79964 though?

OK, so you want: (a) Custom single-select fields (b) The ability for a set of custom single-select fields to be able to use the same list of legal values.

(In reply to comment #8) > (a) Custom single-select fields That is, custom multi-select fields. :-)

The multi-select for version number would work well for the list of "Versions *confirmed* as being affected" and "Versions *confirmed* as not being affected/fixed" Something more than this is required for "Versions *believed* to be affected", particularly for a product which includes code branches and back-porting. My approach (an idea that still needs fleshing out some more if we want to go that way) would be to allow the product admin to populate a table of which versions are "connected", which would be a directed acyclic graph (i.e. similar to the "depends on"/"blocks" relationship of bugs. Any time a new version is added to a product, it would be marked with which version(s?) it is based on. A sufficiently empowered user (permission approx equivalent to "canconfirm") would be able to specify a version number and observation (affected / not affected), together with a confidence level (e.g. 2 confidence levels labelled "confirmed" and "believed") These observations would then automatically propagate to "connected" version numbers, probably at the lowest possible confidence level, with an "unknown" being assigned to versions where there is conflicting information. This seems roughly analogous to user permission propagation in current bugzilla, except that propagation in both directions would be allowable.