1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
<HTML
><HEAD
><TITLE
>Bug Issues</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
"><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
>