Modifying Bugzilla to track a bug across multiple versions with

john fisher john.fisher at
Mon Jan 10 19:57:45 UTC 2005

No doubt worthy suggestions, but they violate the following principles,
which may (?) be helpful:
1) Minimal training allowed for Bugzilla - UI must be obvious.
1A) Things from the real world must be represented as straightforwardly
as possible in the db-
One change to code is tied to one bug, a different change to code has a
separate bug ( though there can be a clone association).
A version is exactly tied to real software versions in CVS, e.g. no
version exists in BZ which is not a tag in CVS.

Caveat: my shop is populated by cranky geezers ( like me ) with no love
for learning new tools.

I didn't say before, but we also made platform and OS product-dependent,
but not multiple- we are going to have a problem when a single release
of our driver runs on multiple platforms. I will probably have to make a
table of legal versions by platform, and change to multiple platforms.


On Thu, 2005-01-06 at 23:47 -0800, timeless wrote:

> Keoni Jacobsen wrote:
> > I am the Bugzilla guru ...would you suggest?
> > 
> > -KJ
> > 
> the approach took was to use keywords.
> 	this requires no coding effort.
> the approach i'm hoping to use for my company is dependencies on aliases.


> one could of course "simply" change the version and target milestone 
> fields from single selects to multi selects ...suppose you took it a step further and 
> allowed multiselect for os/hardware (and really, we should),...
> 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,...

John Fisher at Znyx Networks
Santa Barbara office
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the developers mailing list