show_bug.cgi display layout

[Bill Barry]

> Severity is not the result of a risk assessment on the impact of a 
> fix. It's a measurement of how much of a problem the bug is for how 
> many users. If the thing in question is a problem for users in that 
> sense, then fixing it isn't an enhancement.
If it is a change that allows a user to use the system in a way not 
intended by the original requirements document, then it needs design 
decisions to be made about it (as opposed to just giving it to a 
developer to fix it the way the bug describes) and is an enhancement.

Another difference is that while a bug decribes a problem with some 
known (at the time of writing the bug, perhaps not before) test case. An 
enhancement on the other hand requires new test cases.
>
>> Another aspect of bug 9412 is that there are bugs in bugzilla that 
>> are neither defects (on the product itself) nor enhancements. 
>
> Such as what? And is Bugzilla actually appropriate for tracking them?
As that bug describes:
https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37

>
>> In my opinion the Milestone field is a mistake. I think it would have 
>> been superior to use special milestone bugs and dependencies to make 
>> it very simple to see how multiple bugs are related. A milestone bug 
>> would also have the added benefit of having a deadline.
>
> You could implement any bug grouping in terms of dependencies - we 
> could eliminate the OS field and have an "OS/2" tracking bug on which 
> all OS/2 bugs depend. You would need to argue why Milestone is 
> uniquely suitable for abolishment and replacement in this way.
I don't like, nor do I think OS and Hardware are particularly useful 
either. They allow you to find more specific test cases, and make 
triaging easier, but as single select fields their usefulness is 
limited. I think it would work much better these were right underneath 
the comment section and put in a label "Affects" which would then put in 
the comments "Affects OSxxxx on Hw####" as the last bit of text in each 
comment where a user selects something from the lists. I argue that they 
don't make searching for bugs any easier because I see it happen where 
people cannot find duplicate bugs because they consistently search for 
"Windows XP / All" or "OS X / Macintosh" when they are looking for a bug 
that affects all systems, or has only ever before been seen in "Linux / PC"

Milestone is uniquely suited (compared to hardware and OS) because it is 
truly a single select field (rather than a field that due to another 
long standing bug in Bugzilla only allows one value: 
https://bugzilla.mozilla.org/show_bug.cgi?id=9468). Milestone is not 
unique compared to Version and if it was designed to be the version 
fixed in (as Dave said in another reply on this thread) it would be very 
useful (but again both could very easily be replaced with dependencies 
on specially typed bugs).
>
> It would certainly make searching harder to do. How do you search for 
> bugs fixed in the last three releases? "Depends on bug 12342, 16536 
> and 19354". Hang on - or was it 19345? :-)
Aliases, we already have them to make finding special bugs easier, why 
not use them:
blocks "next_rel"
blocks "future"
blocks  "Bugzilla 3.2"
depends on "reflow"
depends on "gecko_units"
depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18"