Austin English <austinengl...@gmail.com> wrote: >Sent: Jan 26, 2009 11:48 AM >To: James Mckenzie <jjmckenzi...@earthlink.net> >Cc: Alexandre Julliard <julli...@winehq.org>, Paul Vriens ><paul.vriens.w...@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 ><jjmckenzi...@earthlink.net> wrote: >> Alexandre Julliard <julli...@winehq.org> >>>Sent: Jan 26, 2009 7:21 AM >>>To: Paul Vriens <paul.vriens.w...@gmail.com> >>>Cc: James Mckenzie <jjmckenzi...@earthlink.net>, "wine-devel@winehq.org" >>><wine-devel@winehq.org> >>>Subject: Re: Bugzilla question with respect to .NET 1.1SP1 >>> >>>Paul Vriens <paul.vriens.w...@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
