| -rw-r--r-- | sv/choosePackageGroups.html | 23 | | | <HTML
><HEAD
><TITLE
>Bug Issues</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.61
"><LINK
REL="HOME"
TITLE="The Bugzilla Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="The Future of Bugzilla"
HREF="future.html"><LINK
REL="PREVIOUS"
TITLE="Description Flags and Tracking Bugs"
HREF="trackingbugs.html"><LINK
REL="NEXT"
TITLE="Database Integrity"
HREF="dbaseintegrity.html"></HEAD
><BODY
CLASS="SECTION"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Bugzilla Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="trackingbugs.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 6. The Future of Bugzilla</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="dbaseintegrity.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="BUGPROBS"
>6.4. Bug Issues</A
></H1
><P
><P
CLASS="LITERALLAYOUT"
>1. Inline Bug Changes<br>
<br>
Why do I see so many "moving to M5" and "reassigning to blahblah"<br>
messages, and in other circumstances none are entered? Why aren't these<br>
automatically generated? A comment should be only necessary when there<br>
is something to add, and if I'm not interested in this sort of<br>
information, I should be able to hide it.<br>
<br>
At the moment we're in a hybrid world where we don't get everything, but<br>
we can't get rid of the bug change "messages" either. Furthermore,<br>
"View Bug Activity" requires me to manually cross reference events on<br>
another page, rather than being able to visually see the chronological<br>
order. Shouldn't I be able to see all the information on one page?<br>
<br>
A proposal to allow bugs to be shown either way is at<br>
"http://bugzilla.mozilla.org/show_bug.cgi?id=11368".<br>
<br>
2. Hard Wrapping Comments<br>
<br>
One thing that annoys me is the fact that comments are "hard wrapped" to<br>
a certain column width. This is a mistake Internet Mail and News has<br>
made, unlike every word processor in existence, and as a consequence,<br>
Usenet suffers to this day from bad software. Why has Bugzilla repeated<br>
the problem?<br>
<br>
Hard wrapping to a certain column width is open to abuse (see old<br>
Mozilla browsers that didn't wrap properly, resulting in many ugly bug<br>
reports we have to read to this day), and furthermore doesn't expand to<br>
fill greater screen sizes. I'm also under the impression the current<br>
hard wrap uses a non-standard HTML facility. See<br>
"http://bugzilla.mozilla.org/show_bug.cgi?id=11901".<br>
<br>
3. REMIND and LATER Are Evil<br>
<br>
I really hate REMIND and LATER. Not because they mean something<br>
won't be implemented, but because they aren't the best solutions.<br>
<br>
Why are they bad? Well, basically because they are not resolved, yet<br>
they are marked as such. Hence queries have to be well crafted to<br>
include them.<br>
<br>
LATER, according to Bugzilla, means it won't be done this release. <br>
There is a better mechanism of doing this, that is assigning to<br>
nobody@mozilla.org and making the milestone blank. It's more likely to<br>
appear in a casual query, and it doesn't resolve the bug.<br>
<br>
REMIND, according to Bugzilla, means it might still be implemented this<br>
release. Well, why not just move it to a later milestone then? You're<br>
a lot less likely to forget it. If it's really needed, a keyword would<br>
be better.<br>
<br>
Some people can't use blank milestones to mean an untargetted milestone,<br>
since they use this to assess new bugs that have no target. Hence, it<br>
would be nice to distinguish between bugs that have not yet been<br>
considered, and those that really are not assigned to any milestone in<br>
the future (assumedly beyond).<br>
<br>
All this is covered at<br>
"http://bugzilla.mozilla.org/show_bug.cgi?id=13534".<br>
<br>
4. Create An Enhancement Field<br>
<br>
Currently enhancement is an option in severity. This means that<br>
important enhancements (like for example, POP3 support) are not properly<br>
distinguished as such, because they need a proper severity. This<br>
dilutes the meaning of enhancement.<br>
<br>
If enhancement was separated, we could properly see what was an<br>
enhancement. See "http://bugzilla.mozilla.org/show_bug.cgi?id=9412". I<br>
see keywords like [RFE] and [FEATURE] that seem to be compensating for<br>
this problem.</P
></P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="trackingbugs.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="dbaseintegrity.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Description Flags and Tracking Bugs</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="future.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Database Integrity</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
|
|
