Re: Bugzilla question with respect to .NET 1.1SP1
On Mon, Jan 26, 2009 at 1:03 PM, James Mckenzie wrote: > Austin English 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
Re: Bugzilla question with respect to .NET 1.1SP1
Austin English wrote: >Sent: Jan 26, 2009 11:48 AM >To: James Mckenzie >Cc: Alexandre Julliard , Paul Vriens >, "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 > wrote: >> Alexandre Julliard >>>Sent: Jan 26, 2009 7:21 AM >>>To: Paul Vriens >>>Cc: James Mckenzie , "wine-devel@winehq.org" >>> >>>Subject: Re: Bugzilla question with respect to .NET 1.1SP1 >>> >>>Paul Vriens 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
Re: Bugzilla question with respect to .NET 1.1SP1
On Mon, Jan 26, 2009 at 12:34 PM, James Mckenzie wrote: > Alexandre Julliard >>Sent: Jan 26, 2009 7:21 AM >>To: Paul Vriens >>Cc: James Mckenzie , "wine-devel@winehq.org" >> >>Subject: Re: Bugzilla question with respect to .NET 1.1SP1 >> >>Paul Vriens 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. 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. -- -Austin
Re: Bugzilla question with respect to .NET 1.1SP1
Alexandre Julliard >Sent: Jan 26, 2009 7:21 AM >To: Paul Vriens >Cc: James Mckenzie , "wine-devel@winehq.org" > >Subject: Re: Bugzilla question with respect to .NET 1.1SP1 > >Paul Vriens 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
Re: Bugzilla question with respect to .NET 1.1SP1
Alexandre Julliard wrote: > Paul Vriens writes: > >> Alexandre Julliard wrote: >>> Paul Vriens 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. >>> >> Only a comment will not increase the 'popularity' of a bug though. How >> do we determine the priority of such a bug? (Or don't we deal with >> priorities anyway?). > > We don't really, and a separate bug which will be closed as duplicate > wouldn't help anyway. If there is evidence that it affects a lot of apps > you can make the severity major. > OK, fair enough. I'll just have this already existing bug linked to from the appdb then. -- Cheers, Paul.
Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens writes: > Alexandre Julliard wrote: >> Paul Vriens 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. >> > Only a comment will not increase the 'popularity' of a bug though. How > do we determine the priority of such a bug? (Or don't we deal with > priorities anyway?). We don't really, and a separate bug which will be closed as duplicate wouldn't help anyway. If there is evidence that it affects a lot of apps you can make the severity major. -- Alexandre Julliard julli...@winehq.org
Re: Bugzilla question with respect to .NET 1.1SP1
Alexandre Julliard wrote: > Paul Vriens 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. > Only a comment will not increase the 'popularity' of a bug though. How do we determine the priority of such a bug? (Or don't we deal with priorities anyway?). -- Cheers, Paul.
Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens 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. -- Alexandre Julliard julli...@winehq.org
Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens wrote: >Sent: Jan 26, 2009 7:10 AM >To: James Mckenzie >Cc: "wine-devel@winehq.org" >Subject: Re: Bugzilla question with respect to .NET 1.1SP1 > >James Mckenzie wrote: >> Paul Vriens >>> Sent: Jan 26, 2009 4:45 AM >>> To: "wine-devel@winehq.org" >>> Subject: Bugzilla question with respect to .NET 1.1SP1 >>> >>> Hi, >>> >>> I have an application that won't install because it's trying to first do an >>> install of .NET 1.1 and straight after that an upgrade/update to SP1. >>> >>> .NET 1.1SP1 install fails (see bug >>> http://bugs.winehq.org/show_bug.cgi?id=13995). >>> >>> Should I create a new bug report and say that it depends on 13995, should I >>> create a bugreport that is then marked as a duplicate of 13995 or should I >>> just >>> add my findings to 13995? >>> >> If it is a separate application, separate bug report. If the same >> application is affected, update. Since it appears that you are using a >> different application to install .NET 1.1 SP1, then a new report should be >> submitted and then linked to issue 13995. The reason I state this is that >> additional problems may be discovered, even after .NET 1.1 SP1 runs and >> installs. It may also be possible to get your application to run, even if >> .NET 1.1 SP1 will not fully install. >> >> I would classify this as an application does not install because .NET 1.1 >> SP1 will not install properly. >> >> James McKenzie >> >> >So that means bug 14850 needs to be reopened with a link to 13995? > If the problem may be outside of .NET 1.1 SP1, yes. If not, then the answer is no. I'll have to look at the two bug reports and see if they are related and true duplicates. James McKenzie
Re: Bugzilla question with respect to .NET 1.1SP1
James Mckenzie wrote: > Paul Vriens >> Sent: Jan 26, 2009 4:45 AM >> To: "wine-devel@winehq.org" >> Subject: Bugzilla question with respect to .NET 1.1SP1 >> >> Hi, >> >> I have an application that won't install because it's trying to first do an >> install of .NET 1.1 and straight after that an upgrade/update to SP1. >> >> .NET 1.1SP1 install fails (see bug >> http://bugs.winehq.org/show_bug.cgi?id=13995). >> >> Should I create a new bug report and say that it depends on 13995, should I >> create a bugreport that is then marked as a duplicate of 13995 or should I >> just >> add my findings to 13995? >> > If it is a separate application, separate bug report. If the same > application is affected, update. Since it appears that you are using a > different application to install .NET 1.1 SP1, then a new report should be > submitted and then linked to issue 13995. The reason I state this is that > additional problems may be discovered, even after .NET 1.1 SP1 runs and > installs. It may also be possible to get your application to run, even if > .NET 1.1 SP1 will not fully install. > > I would classify this as an application does not install because .NET 1.1 SP1 > will not install properly. > > James McKenzie > > So that means bug 14850 needs to be reopened with a link to 13995? -- Cheers, Paul.
Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens >Sent: Jan 26, 2009 4:45 AM >To: "wine-devel@winehq.org" >Subject: Bugzilla question with respect to .NET 1.1SP1 > >Hi, > >I have an application that won't install because it's trying to first do an >install of .NET 1.1 and straight after that an upgrade/update to SP1. > >.NET 1.1SP1 install fails (see bug >http://bugs.winehq.org/show_bug.cgi?id=13995). > >Should I create a new bug report and say that it depends on 13995, should I >create a bugreport that is then marked as a duplicate of 13995 or should I >just >add my findings to 13995? > If it is a separate application, separate bug report. If the same application is affected, update. Since it appears that you are using a different application to install .NET 1.1 SP1, then a new report should be submitted and then linked to issue 13995. The reason I state this is that additional problems may be discovered, even after .NET 1.1 SP1 runs and installs. It may also be possible to get your application to run, even if .NET 1.1 SP1 will not fully install. I would classify this as an application does not install because .NET 1.1 SP1 will not install properly. James McKenzie
Bugzilla question with respect to .NET 1.1SP1
Hi, I have an application that won't install because it's trying to first do an install of .NET 1.1 and straight after that an upgrade/update to SP1. .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995). Should I create a new bug report and say that it depends on 13995, should I create a bugreport that is then marked as a duplicate of 13995 or should I just add my findings to 13995? Bug 9140 for example is a separate report with a dependence on 13995. And bug 14850 is marked as a duplicate of 13995. -- Cheers, Paul.
