<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bill Barry wrote:
<blockquote cite="mid45B0D78E.5080808@gmail.com" type="cite"><br>
<blockquote type="cite">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.
<br>
</blockquote>
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.
<br>
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid45B0D78E.5080808@gmail.com" type="cite">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.
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid45B0D78E.5080808@gmail.com" type="cite">
<blockquote type="cite"><br>
<blockquote type="cite">Another aspect of bug 9412 is that there
are bugs in bugzilla that are neither defects (on the product itself)
nor enhancements. </blockquote>
<br>
Such as what? And is Bugzilla actually appropriate for tracking them?
<br>
</blockquote>
As that bug describes:
<br>
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37">https://bugzilla.mozilla.org/show_bug.cgi?id=9412#c37</a>
<br>
<br>
</blockquote>
... errata, documentation tracking issues, status trackers, ...<br>
<blockquote cite="mid45B0D78E.5080808@gmail.com" type="cite">
<blockquote type="cite"><br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
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"
<br>
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid45B0D78E.5080808@gmail.com" type="cite">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:
<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=9468">https://bugzilla.mozilla.org/show_bug.cgi?id=9468</a>). 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).
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid45B0D78E.5080808@gmail.com" type="cite">
<blockquote type="cite"><br>
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? :-)
<br>
</blockquote>
Aliases, we already have them to make finding special bugs easier, why
not use them:
<br>
blocks "next_rel"
<br>
blocks "future"
<br>
blocks "Bugzilla 3.2"
<br>
depends on "reflow"
<br>
depends on "gecko_units"
<br>
depends on "Bugzilla 2.10" and blocks "Bugzilla 2.18"
<br>
</blockquote>
<br>
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.<br>
<br>
<div class="moz-signature">-- <br>
<img src="cid:part1.07010401.06000504@amd.com" border="0"></div>
</body>
</html>