Bugzilla question with respect to .NET 1.1SP1

[Austin English]

On Mon, Jan 26, 2009 at 1:03 PM, James Mckenzie
<jjmckenzie51 at earthlink.net> wrote:
> Austin English <austinenglish at gmail.com> wrote:
>>That's messy. Have them cc themselves to the original bug, and when
>>its fixed, retest. No need to file a bug only to close it immediately
>>as a duplicate.
>>
> I realize it's ugly, but I'm thinking like a software tester not a developer.  If I found three bugs in a program, I opened three bugs.  If I found the same bug in a different program, I opened a second bug and attached it to the first.

Different bugs deserve different reports, yes. But the same bug in
different program does not. Wine already has thousands of bugs, we
don't need more frivolous ones.

>>If, however, you're able to workaround that bug, then make a new bug,
>>and have the second depend on the first.
>>
>>E.g., program foo needs native gdiplus and native richedit to install.
>>File bug for gdiplus problem, then file a second one for richedit,
>>marking it as depending on the gdiplus bug.
>
> What if the richedit bug is fixed first?  Would it be impossible to test to see if the bug is fixed?  If that were the case, then this is a correct scenario.  If the richedit bug can be tested independently of the gdiplus bug, then this scenario is incorrect.  If the gdiplug bug depends on the richedit bug being fixed first, then the linkage should be reversed.  Linking two separate bugs in this case may not pass the sense test.

Perhaps that was unclear. A bit better of an explanation:
I go to install Adobe reader. Installer immediately exits because of a
problem with gdiplus. I file a bug for gdiplus problem, then run
'winetricks -q gdiplus'. Next up, the EULA is blank. I see it's a
problem with richedit, file a bug, and solve it with 'winetricks -q
riched20'. Carry on with installer, and use the app for it's intended
purpose.

I'd then mark the richedit bug as depending on the gdiplus bug.

> There has to be an added, simple mechanism where a user (not a developer, or triage) can add to a list of applications affected by a specific bug.

That's the purpose of the AppDB, for knowing what bugs affect a
program, how to work around them, etc. Bugzilla is for reporting and
fixing bugs.

> See above for what I consider a bug, this is a single application affected by a single problem.  Linking together independent bugs needs to be done in a rational manner.  If three applications are affected by the same bug, then they either should be linked together, reported under one bug with additional votes for the added applications and users with an updated description, or held as separate bug reports.

Understandable, but keep in mind that few people triage most bugs.
Dmitry, Vitaliy and myself seem to be ones most often triaging bugs.
Dan, Juan, Hans, Lei and others (no offense to those left out) help
quite a bit as well. I encourage you to subscribe to wine-bugs for a
while and triage all the bug reports. Once you get a sense of all the
duplicates, you'll understand my viewpoint better. Especially when
something like the 1.1.12 regressions occur.

> Sorry to be so long winded about this, but proper bug reporting was and still is my primary business.

Again, understandable, but this is Wine's Bugzilla, not crossover's.
It's a volunteer project, and Bugzilla is not there to track every bug
in every app, but rather to track each bug in Wine...a subtle, yet
important, difference.

The AppDB is great for these sorts of things. If a bug affects
multiple apps, list it there. Most people search AppDB for getting
their app to run, not Bugzilla. They can always add a comment to the
bug saying it affect X app as well. For those bugs, the summary can
(and usually is) adjusted accordingly.

--
-Austin