show_bug.cgi display layout

[Kevin Benton]

Bill Barry wrote:
>
>> 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.
>

Since the severities are now customizable, it's possible to set your own 
definitions and include things like Enhancement is Business Critical, 
Enhancement is Needed, Enhancement is Wanted, etc...  That would allow 
your customer to specify how important the enhancement request was to them.

> 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.

A well-written enhancement request includes an adequate specification, 
thus providing a minimal set of test cases.  Many times, however, when 
an enhancement request is made, there isn't enough information available 
to make a good (set of) test case(s).  As I see it, determining good 
test cases for an enhancement request requires that it's feasible to 
write the enhancement first, then if so, write the 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
>
... errata, documentation tracking issues, status trackers, ...
>>
>>> 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"
>

We agree to disagree then.  When your QA team requires that a bug is 
filed per impacted Hardware & OS so that their work is tracked in each 
bug separately, then OS and Hardware as single-select fields are very 
meaningful.  There's nothing wrong with adding an OS or Hardware label 
that others agree includes a group of platforms.

> 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).

I agree that it seems that Milestone could be better if it were directly 
tied to the versions table.  I also agree that there are times when it's 
useful to track found_in_rev versus fixed_in_rev versus 
planned_for_rev.  I've been side-tracked from finishing up my impact 
table, however, one of my implementations in that update is to 
incorporate versions at the component level.  Here, we actually track 
all three of these version fields.  Milestones has been changed to 
planned_for_rev.  Version has been changed to found_in_rev.  A new field 
(fixed_in_rev) was added so we know exactly when a version was fixed, 
not just when was it originally planned for.  We're considering 
incorporating also_in_revs so we know when a fix is applied to a number 
of versions.

>>
>> 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"

Because you can only have one alias pointing to a single bug in the 
entire DB.  Using a milestone, keyword or flag makes more sense.

-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070119/83c869a1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AMDLogo.png
Type: image/png
Size: 1784 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070119/83c869a1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kevin.benton.vcf
Type: text/x-vcard
Size: 915 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20070119/83c869a1/attachment.vcf>