Bug Issues

The Bugzilla Guide
Prev | Chapter 6. The Future of Bugzilla | Next

# 6.4. Bug Issues

1. Inline Bug Changes
Why do I see so many "moving to M5" and "reassigning to blahblah"
messages, and in other circumstances none are entered? Why aren't these
automatically generated? A comment should be only necessary when there
is something to add, and if I'm not interested in this sort of
information, I should be able to hide it.
At the moment we're in a hybrid world where we don't get everything, but
we can't get rid of the bug change "messages" either. Furthermore,
"View Bug Activity" requires me to manually cross reference events on
another page, rather than being able to visually see the chronological
order. Shouldn't I be able to see all the information on one page?
A proposal to allow bugs to be shown either way is at
"http://bugzilla.mozilla.org/show_bug.cgi?id=11368".
2. Hard Wrapping Comments
One thing that annoys me is the fact that comments are "hard wrapped" to
a certain column width. This is a mistake Internet Mail and News has
made, unlike every word processor in existence, and as a consequence,
Usenet suffers to this day from bad software. Why has Bugzilla repeated
the problem?
Hard wrapping to a certain column width is open to abuse (see old
Mozilla browsers that didn't wrap properly, resulting in many ugly bug
reports we have to read to this day), and furthermore doesn't expand to
fill greater screen sizes. I'm also under the impression the current
hard wrap uses a non-standard HTML facility. See
"http://bugzilla.mozilla.org/show_bug.cgi?id=11901".
3. REMIND and LATER Are Evil
I really hate REMIND and LATER. Not because they mean something
won't be implemented, but because they aren't the best solutions.
Why are they bad? Well, basically because they are not resolved, yet
they are marked as such. Hence queries have to be well crafted to
include them.
LATER, according to Bugzilla, means it won't be done this release.
There is a better mechanism of doing this, that is assigning to
nobody@mozilla.org and making the milestone blank. It's more likely to
appear in a casual query, and it doesn't resolve the bug.
REMIND, according to Bugzilla, means it might still be implemented this
release. Well, why not just move it to a later milestone then? You're
a lot less likely to forget it. If it's really needed, a keyword would
be better.
Some people can't use blank milestones to mean an untargetted milestone,
since they use this to assess new bugs that have no target. Hence, it
would be nice to distinguish between bugs that have not yet been
considered, and those that really are not assigned to any milestone in
the future (assumedly beyond).
All this is covered at
"http://bugzilla.mozilla.org/show_bug.cgi?id=13534".
4. Create An Enhancement Field
Currently enhancement is an option in severity. This means that
important enhancements (like for example, POP3 support) are not properly
distinguished as such, because they need a proper severity. This
dilutes the meaning of enhancement.
If enhancement was separated, we could properly see what was an
enhancement. See "http://bugzilla.mozilla.org/show_bug.cgi?id=9412". I
see keywords like [RFE] and [FEATURE] that seem to be compensating for
this problem.

Prev | Home | Next
Description Flags and Tracking Bugs | Up | Database Integrity