Modifying Bugzilla to track a bug across multiple versions with

[timeless]

Keoni Jacobsen wrote:
> I am the Bugzilla guru for the company I work for.  We want to modify
> Bugzilla, and I was looking for advice on how to do this.  I'm not
> asking for any technical help.  We have good people working on this.
> (Well, it's just me, but I can handle it.)  I was trying to figure out
> how to make this look for the users and managers.
> 
> Here is the situation: we have bugs and we have different versions of
> our product.  We can find bugs in one version of our product, and we
> know it may exist in other versions of our product.  A bug can get
> fixed in one version, but, life being what it is, it may not get fixed
> in other versions.
> 
> We want to be able to track what versions a bug appears in, and where
> it gets fixed.  So, the single bug status isn't adequate for this.  We
> can't just say a bug is resolved if it's fixed in the most recent
> version if it isn't fixed in the previous version.
> 
> What we've been doing is opening up new bugs for each version.  But
> it's a pain trying to keep all the bugs straight, and seeing what bugs
> are really the same as other bugs, just in different versions.  It
> messes up bug dependencies, and it makes it hard to link to our
> customer issues.
> 
> So, I want to find a way to make things easier on everybody.  What
> scheme would you suggest?
> 
> -KJ
> 
> P.S. Please forgive the obfuscated E-mail address.  I'm just trying to
> avoid the plague of the Internet (aka spam).
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=timeless@myrealbox.com>

the approach mozilla.org took was to use keywords.
	this requires no coding effort.

the approach i'm hoping to use for my company is dependencies on aliases.
	this can be done without any coding effort. a bug is dependent on 
open_1.7 and when it's fixed there, it's changed to being dependent on 
fixed_1.7 (you have to pick which way you want the dependency to go, or 
do a bit more work and add the related bug list). To make it pretty 
would require dependencies to be displayed by their aliases instead of 
their bug ids, and to deal with what happens when someone moves an alias 
and someone else commits a change to a which was dependent on the alias.

you're already sort of using one of the other options, namely forked 
bugs (most likely you'd want to use a related bug field - i need to find 
a bug number about this).

one could of course "simply" change the version and target milestone 
fields from single selects to multi selects (this is of course a schema 
change, and requires dealing w/ users who accidentally clear the 
selection). there's something to be said for this 'simple' solution, 
until you consider combinations. suppose you took it a step further and 
allowed multiselect for os/hardware (and really, we should), what 
happens when a bug is fixed for all hardware in one version and some 
hardware for another version :). at some point you really do need to 
fork bugs and rearrange the /flags/ (however you implement them).

lastly, i suppose, you can go for a system where you have at least two 
types of bugs, the first type tracks analysis and resolution, the second 
type is filed for each case where a fix is committed, included in such a 
bug is always a list of commits (or however your changes are tracked, 
personally i use 
http://bonsai.mozilla.org/cvslog.cgi?file=whatever&mark=EACH,COMMITTED,VERSION 
.) the former blocks the latter, and people never include commit 
messages into analysis bugs.