On Thu, 26 Mar 2009 17:11:13 -0700 (PDT) Valerie Bubb Fenwick
<valerie.fenw...@sun.com> wrote:
> * Auditing of administrative changes
We want this upstream as well. We'd be happy to work with
somebody to integrate this upstream if you want to assign a developer
to it. It does require a bit of refactoring first, most of which is
ongoing already though (but would have to be done by said developer if
it's not finished by the time they start work).
> * 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.
There are various proposals for how this can work at:
https://bugzilla.mozilla.org/show_bug.cgi?id=540
There are lots of comments, but just read around comment 63,
that's all that matters.
> * 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.]
Yes, Bugzilla can already do all this.
> * Ability to store customer call records (aka SRs) confidentially.
Bugzilla can store any bug report confidentially.
> * Ability to keep some bugs confidential due to contractual
> obligations.
Bugzilla can do this.
> * 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.
Hmm?
> * Need ability to view descriptions of components before clicking
> through to do a submit. There should be an easy way to view these.
Already exists in Bugzilla 3.2.
> * It is very important to have a full text search engine.
Already exists in the Bugzilla you are running. It might be
better in Bugzilla 3.2 though.
> * 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.
You're looking at something like 500 hours of work, I'd guess,
there, which would end up as a customization so massive that you could
never upgrade to any future version of Bugzilla. There are entire
products that do Bugzilla metrics that you might want to look into
instead of using Bugzilla's internal charts.
> * 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.
You could also just create categories for the most common
combinations, for OS and hardware. What we have always found is that
"just one" or "all" are the only two combinations that tend to matter
in practice, for those. I've never had a circumstance or filed a bug in
any Bugzilla where I needed to say that multiple certain OS/hardware was
affected, but not all were affected.
> * 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.
That's not just an example--that's the *only* thing that you
can't do in one transaction.
I'd wait for upstream to achieve that feature. I don't think
it's really that big of an issue, particularly if you enable mod_perl
so that page submits are much faster. I'd suggest taking this off the
"blocker" list and maybe putting it into the "annoying" list.
> * Bugzilla lacks the "see also" undirected connection between bugs.
Bugzilla 3.4 will have this.
> * 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.
Feel free to submit a patch upstream.
> * 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.
That's basically this:
https://bugzilla.mozilla.org/show_bug.cgi?id=283695
With a few enhancements that we do want.
> * 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.
That you would have to do as a customization.
> * 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.)
You could give everybody the editkeywords permission, though I
wouldn't recommend it.
> * 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.
You could customize Bugzilla 3.4's "See Also" field to do this.
> * Lack of ability to track the progress of the bug in multiple
> releases, which is relied on heavily by Solaris. (subCRs)
https://bugzilla.mozilla.org/show_bug.cgi?id=bz-branch
> * Need to be able to add user aliases to the CC of a bug. Currently
> we can't do this in bugzilla.
What are user aliases? Why don't you create fake accounts for
them?
> * 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.
Um, Bugzilla has an XML-RPC interface...
> * Fields need to be properly sized in the bugzilla GUI to ease
> viewing (received complaints about the description)
That's fixed. You *are* running a development build, after all.
I don't remember if we adjusted the summary field for 3.2 or 3.4,
though. But the UI for 3.2 is very different than the one you are using.
> * Need Introduced in release/build information.
Can easily be done with a custom field.
> * Need "solution" information like Patch IDs, InfoDocs, etc.
Could easily be custom fields.
> * Need Verified state in bugzilla
Um, it ships with one. Did you delete it?
> * The UNCONFIRMED status for the defect should not exist in our
> implementation of bugzilla.
Then you just have to change the "votes" parameters for each
products so that all bugs take 0 votes to confirm.
HOWEVER, if you are going to accept public bug submissions, I
would highly recommend you keep UNCONFIRMED enabled. It's an excellent
way to note publicly-reported bugs that haven't been triaged. As your
bug reporting rate increases, this will become more and more important.
> * If we fully switch to bugzilla, all existing bugster bugs will
> need to be moved. We cannot live without our history.
Feel free to talk to me about ways to do this. I've done this
for lots of organizations.
> * 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.
https://bugzilla.mozilla.org/show_bug.cgi?id=278455
> * Saved custom bug templates, like we have in bugster (in the way of
> default new CR preferences).
This is not that hard a customization, particularly given the
Bookmarkable Template functionality that exists in Bugzilla.
> * 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.
Do people really type more than 100 characters frequently into
your summary lines? Anyhow, this is an easy UI customization.
> * 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)
Yes, it is fixed.
> * 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.
It is however very nice for people who receive hundreds of
bugmails a day.
> * 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.
In most engineering environments I've been in, forcing comments
has been mostly an annoying roadblock that causes people to do things
like type "." in the comment field.
> * 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.
We have have "user" custom fields in the future:
https://bugzilla.mozilla.org/show_bug.cgi?id=287332
> * A recently edited/viewed list, like we have in bugster, would
> be nice to have.
Yeah, that would be nice.
> * Being able to search "reported by" is very useful in bugster.
You can do that in Bugzilla.
> * "Root cause" and "introduced in build" fields are frequently used.
You could easily add custom fields for those.
> * Please add "order number" for search result, then it is easy to
> calculate the bug numbers for different severity level.
Hmm?
> * Email aliases in bugzilla seem to be currently limited to 20
> characters, which is too restrictive.
Those aren't email aliases. Those are bug aliases.
> * By default, submitter does not receive email updates. This is
> annoying, trying to always remember to add yourself.
That's not true, unless you've customized it or set your email
preferences that way. It is true that by default the person making any
particular change does not get email for that change, but they can
change their preferences.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
