show_bug.cgi display layout
after.fallout at gmail.com
Fri Jan 19 14:37:02 UTC 2007
> 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:
>> 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 "Bugzilla 3.2"
depends on "reflow"
depends on "gecko_units"
depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18"
More information about the developers