Modifying Bugzilla to track a bug across multiple versions with
john.fisher at znyx.com
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 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...
More information about the developers