Modifying Bugzilla to track a bug across multiple versions with

[john fisher]

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.

HTH
John


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 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.

...

> 
> 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: <http://lists.bugzilla.org/pipermail/developers/attachments/20050110/02285b5b/attachment.html>