Hi everyone - Here are the results of the bugzilla gaps gathering we ran earlier this month. We are providing this merely to show what has been captured, and not as any commitment to fix or have fixed any of these issues.
Valerie Fenwick & Scott Rotondo Things we must have in order to use bugzilla for the enterprise: ================================================================ * Secure login (this is possible with the right certificate setup) * Secure storage of passwords on the system (this is possible if we upgrade to a much more modern version of bugzilla, if properly configured) * Auditing of administrative changes * Need a method for editing existing comments. The way bugzilla is now, you have to be extremely careful to get everything right the first time, since any updates you might want to make may get lost in the noise of future comments. * Ability to bowdlerize bug reports that contain security vulnerability related information or confidential information of other sorts. In bugster, we have the "Is this a Security Vulnerability?" field and associated handling in the boundary systems. Also, we have entire "products" (like Solaris's "development" product), that are internal only. [ED note: there seems there may be some functionality related to restriction views/edits to specific "groups" that our database is not set up to use at this time.] * Ability to store customer call records (aka SRs) confidentially. * Ability to keep some bugs confidential due to contractual obligations. * Three tuple hierarchy, so multiple products can share one repo. otherwise we may end up with hundreds of uniquely maintained repos for various Sun products. * Need ability to view descriptions of components before clicking through to do a submit. There should be an easy way to view these. * It is very important to have a full text search engine. * Need a way for users to be able to set up charts and graphs. Currently they need to be set up by an administrator and they do not work on historical data. * Need ability to associate multiple releases/OS/hardware values to one defect. Currently bugzilla only allows one, whereas bugster can reflect the real world with multiple SRs. * Need to be able to do multiple transactions at once for one bug. For example, in bugzilla you can't currently add an attachment and do anything besides add a comment. This is a major productivity concern. * Bugzilla lacks the "see also" undirected connection between bugs. * When bug A gets marked as a duplicate of bug B, a comment to that effect is added to each bug's comment log. If that turns out to have been incorrect, and the duplication is removed, the comments stay. This should not happen. * There is no distinction in bugzilla for what *type* of comment it is, for example how do we identify Work Around, Evaluation or just a comment? Also, many requests to maintain Suggested Fix field. * There's no way to associate bug state with a particular build. There's "target milestone", which sort of corresponds to "commit to fix in build", but there's no "fixed in build" or "integrated in build" or "verified in build", etc, all of which should use the same list of milestones. * General access to keywords. As it stands, you have to have some sort of special administrative access in Bugzilla to create keywords. I'm able to create user accounts, products, and flags, but I can't touch keywords. In Bugster, keywords are just plain old text strings; anyone can use whatever they want. (Minor downside of the Bugster way: some people misunderstand keywords and just stuff the summary in there, larding the database with junk.) * Having cross-references to escalations is extremely handy, so that RPE and development don't step on each other. Escalation internals would need to be confidential, of course. * Lack of ability to track the progress of the bug in multiple releases, which is relied on heavily by Solaris. (subCRs) * Need a two level release/build mechanism. Bugzilla only has a single release field, which will get unwieldy as we generate more releases. * Facility functionally equivalent to Monaco Expert Interface, this is an essential tool we use for productivity and test gap analysis. * Need to be able to add user aliases to the CC of a bug. Currently we can't do this in bugzilla. * Allow for script-based query and updates. A simple command-line front-end would allow a lot of custom scripts to be written that makes the tool more efficient to use. bugster has an XML-based access and SQL frontend access that many teams rely on. * Integration with boundary systems like monaco and SunSolve. * Fields need to be properly sized in the bugzilla GUI to ease viewing (received complaints about the description) * Need Introduced in release/build information. * Need "solution" information like Patch IDs, InfoDocs, etc. * Need Verified state in bugzilla * The UNCONFIRMED status for the defect should not exist in our implementation of bugzilla. * Need to have a field like "target build" * If we fully switch to bugzilla, all existing bugster bugs will need to be moved. We cannot live without our history. Things we strongly desire/painful to live without: ================================================== * While at the current level, interest lists are a "nice to have", if we're going to move to bugzilla for everything, we really do need a more scalable solution. Having to go in and create a watcher alias for every single component is tedious. * Saved custom bug templates, like we have in bugster (in the way of default new CR preferences). * The summary field in bugzilla is 255 characters long. The 100 character limit in Bugster is nice, in that it limits people from going on and on in the summary. * The hack of using the QA contact as a place to stick a watcher alias has the side effect that when moving bugs from one component to another, the new alias isn't automatically moved to the new component's QA. By now, many of us know that we have to reset the Assignee and QA contact when moving bugs, but not everyone does, and so sometimes bugs will get moved, but missed. (Note: This may be fixed in a newer version than what we've deployed) * Email shows only the changes made, rather than displaying the entire bug. That could be construed as good or bad, though when a bug is moved from one component to another, it can be a bit annoying not to have the bug history immediately in your inbox. * Justifications, when used properly, are a good thing in Bugster, and force people changing priorities to _think_ about why the new priority is right and the old one was wrong. Bugzilla doesn't seem to have this. * The RM field in Bugster is really a "non-NULL technology owner" field. It would be nice to have a field like this in Bugzilla: something automatically assigned by the Component selected that gives an owner that can be contacted about progress (or lack thereof) for a bug, regardless of what "Assignee" is set. This would be sort of like the "QA Contact" field, but would very likely have a _real_ email address. * A recently edited/viewed list, like we have in bugster, would be nice to have. * Being able to search "reported by" is very useful in bugster. * "Root cause" and "introduced in build" fields are frequently used. * Please add "order number" for search result, then it is easy to calculate the bug numbers for different severity level. * Email aliases in bugzilla seem to be currently limited to 20 characters, which is too restrictive. * By default, submitter does not receive email updates. This is annoying, trying to always remember to add yourself. Other differences ================= * RFEs are just a distinct Severity of bug. I'm not sure whether that's bad or not, though it can be pretty weird. * There's no concept of "initial evaluator", as distinct from the aliases that get a copy of every single bug mail. _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
