Austin English austinenglish@gmail.com wrote:
Sent: Jan 26, 2009 11:48 AM To: James Mckenzie jjmckenzie51@earthlink.net Cc: Alexandre Julliard julliard@winehq.org, Paul Vriens paul.vriens.wine@gmail.com, "wine-devel@winehq.org" wine-devel@winehq.org Subject: Re: Bugzilla question with respect to .NET 1.1SP1
On Mon, Jan 26, 2009 at 12:34 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
Alexandre Julliard julliard@winehq.org
Sent: Jan 26, 2009 7:21 AM To: Paul Vriens paul.vriens.wine@gmail.com Cc: James Mckenzie jjmckenzie51@earthlink.net, "wine-devel@winehq.org" wine-devel@winehq.org Subject: Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens paul.vriens.wine@gmail.com writes:
So that means bug 14850 needs to be reopened with a link to 13995?
No, if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem.
Actually, I have a different opinion as the reason a program will not install may, at first appearance, be the lack of .NET1.1SP1 but may be another function that Wine does not provide. Paul is 'smart enough' to figure that the problem IS the lack of .NET functionality or the inability to install, but the common user may not. I say, open the bug, mark it as a duplicate of the existing bug and then close it. Add the reporter as a cc to the original bug. When the bug is resolved, then have the user attempt to install the program, if it still fails, reopen the duplicate with whatever does not work now. This keeps the number of bugs down and lets us know how much the lack of functionality affects the Wine user base. Some users complain of being lost in the shuffle because they add to an existing bug that another program is affected.
What do you say about doing this?
James McKenzie
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.
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.
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. 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.
Sorry to be so long winded about this, but proper bug reporting was and still is my primary business.
James McKenzie
On Mon, Jan 26, 2009 at 1:03 PM, James Mckenzie jjmckenzie51@earthlink.net wrote:
Austin English austinenglish@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
-
Austin English -
James Mckenzie