267874 - Version Handling: "versions believed to be affected" and "versions confirmed as being affected"

Status: RESOLVED DUPLICATE of bug 79964

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Jason Bucata]

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:

Comment 1

[Joel Peshkin]

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?

Comment 2

[Jason Bucata]

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.

Comment 3

[Dave Miller [:justdave]]

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.

Comment 4

[Max Kanat-Alexander]

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

Comment 5

[Jason Bucata]

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

Comment 6

[Stuart Donaldson]

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.

Comment 7

[Stephen Lee]

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?

Comment 8

[Max Kanat-Alexander]

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.

Comment 9

[Max Kanat-Alexander]

(In reply to comment #8)
> (a) Custom single-select fields

  That is, custom multi-select fields. :-)

Comment 10

[Stephen Lee]

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.