Bugzilla administration policies
Hi, I really appreciate the effort everyone has put into cleaning out the old bugs in our bugzilla recently; however, I do have an issue with the way we're closing some of the bug reports. The ultimate outcome of wine is to enable a user to run windows apps just as they would in windows, so if a user has to run the app with a native dll or follow special instructions to make it work, then there is a bug in wine that needs to be fixed. Quite a few bugs have been closed recently referring the user to the instructions in the AppDB or to a list of dll overrides that makes the app work. Recommending a dll override can be useful to the end user as a temporary workaround, but the bug hasn't been fixed. Cleaning out the bugzilla is well appreciated, but we must keep up due diligence in order to keep wine's bugzilla as a reliable status of wine's bugs. I offer this as the beginning of a discussion of bugzilla administration policies. Any thoughts, comments, and ideas are welcome. -- James Hawkins
On 10/9/05, James Hawkins <truiken(a)gmail.com> wrote:
Quite a few bugs have been closed recently referring the user to the instructions in the AppDB or to a list of dll overrides that makes the app work. Recommending a dll override can be useful to the end user as a temporary workaround, but the bug hasn't been fixed.
Good point. Got a few examples bug numbers that were resolved like that?
Dan Kegel wrote:
Good point. Got a few examples bug numbers that were resolved like that?
See http://bugs.winehq.org/show_bug.cgi?id=2858 I recently resolved a lot of whiskery old bugs, essentially "IE6 installer fails", with directions to the AppDB, because it fixes the user's problem, and IE6 will install the DLLs it needs. But http://bugs.winehq.org/show_bug.cgi?id=587 "Create replacement of browser component (Internet Explorer/IE)" remains open. Richard.
On 10/10/05, Richard Cohen <richard(a)daijobu.co.uk> wrote:
See http://bugs.winehq.org/show_bug.cgi?id=2858
I recently resolved a lot of whiskery old bugs, essentially "IE6 installer fails", with directions to the AppDB, because it fixes the user's problem, and IE6 will install the DLLs it needs.
Marking the other bugs as duplicates of 2858 was probably fine, but I think we ought to leave 2858 open, or if we do not plan to fix it, mark it "WILLNOTFIX" rather than "FIXED". The instructions in the appdb are arguably a workaround rather than a fix.
But http://bugs.winehq.org/show_bug.cgi?id=587 "Create replacement of browser component (Internet Explorer/IE)" remains open.
That's fine; I think "IE not installing" is a separate issue.
Dan Kegel wrote:
Marking the other bugs as duplicates of 2858 was probably fine, but I think we ought to leave 2858 open, or if we do not plan to fix it, mark it "WILLNOTFIX" rather than "FIXED". The instructions in the appdb are arguably a workaround rather than a fix.
I'm happy to do either, but I think it's probably better to keep it open. Richard.
On 10/10/05, Richard Cohen <richard(a)daijobu.co.uk> wrote:
Dan Kegel wrote:
Good point. Got a few examples bug numbers that were resolved like that?
See http://bugs.winehq.org/show_bug.cgi?id=2858
I recently resolved a lot of whiskery old bugs, essentially "IE6 installer fails", with directions to the AppDB, because it fixes the user's problem, and IE6 will install the DLLs it needs.
But http://bugs.winehq.org/show_bug.cgi?id=587 "Create replacement of browser component (Internet Explorer/IE)" remains open.
Here is a list of bugs you recently resolved: 2066: IE6 fails to download the mirror list 2945: IE6 installer hangs after a while 3120: Using certain native dlls, IE6 crashes 1293: IE6 setup cannot download setup files 2308: IE6 setup requests all windows be closed..cannot continue 2711: IE6 cannot start because of an unimplemented shdocvw function 2268: Problem with ntdll file api when installing microsoft products All of the above bugs are marked as duplicates of 2858 (IE6 SP1 fails to install). While most of the above bugs fall under the category of not being able to install IE6, they are individual bugs that need to be addressed, but because 2858 was resolved as FIXED, all of these are now "fixed" when they are more than likely still not fixed. Marking 2858 itself as fixed is an error in that there is no way to install IE6 without using native dlls or special instructions. All of these bugs need to be reopened (including 2858) and marked as blockers of the meta-bug "IE6 fails to install". It's fine to point the users to workarounds in the bugzilla or the wiki, but we can't mark the bugs as fixed just because we have a workaround. -- James Hawkins
James Hawkins wrote: All of these
bugs need to be reopened (including 2858) and marked as blockers of the meta-bug "IE6 fails to install".
Reopening them is pointless, because most of them are so old that ie6setup does not fail in that way anymore. So they would be resolved as fixed until we're left with just one - "IE6 fails to install with the current release". Metabugs are generally a bad idea because they are very hard to maintain. What is the point of "Get games working perfectly", and how can it ever be resolved? Richard.
On 10/10/05, Richard Cohen <richard(a)daijobu.co.uk> wrote:
James Hawkins wrote: All of these
bugs need to be reopened (including 2858) and marked as blockers of the meta-bug "IE6 fails to install".
Reopening them is pointless, because most of them are so old that ie6setup does not fail in that way anymore. So they would be resolved as fixed until we're left with just one - "IE6 fails to install with the current release".
The point is you don't know if they're fixed or not. We resolve these bugs as we would any other bug. We ask for feedback and if they don't respond after a certain amount of time we resolve it abandoned. They aren't duplicates and we don't know whether they are fixed or not, so those two resolutions are invalid. Bug 1293 is a good example of a bug that is still not fixed. IE6 setup consistently fails to download the setup files. Keeping the bug open provides incentive and information for someone to fix it.
Metabugs are generally a bad idea because they are very hard to maintain. What is the point of "Get games working perfectly", and how can it ever be resolved?
Of course metabugs for really ambiguous topics like "Get games working perfectly" is a bad idea. The bug means nothing and could include hundreds of bug reports. "IE6 fails to install" is a specific problem with wine that has at least 7 specific bugs causing the failure. When IE6 installs correctly without workarounds, then the bug has been resolved. Abuse of metabugs in the past shouldn't stop us from using them now. -- James Hawkins
Richard Cohen wrote:
Metabugs are generally a bad idea because they are very hard to maintain. What is the point of "Get games working perfectly", and how can it ever be resolved?
Who said it needs to be resolved, ever, or in any kind of near future? I see metabugs more as a categorization feature. If you want an overview of all games that fail in Wine, go check out that particular entry. I'd like to see metabugs for each DLL or larger area, for instance "Window painting in Wine". I can see a number of bugs that would fit that metabug, and I think it might make it easier for some people to see when a particular area of Wine is mature enough for release (in an easy to administrate manner). There's probably other bonuses from keeping the bugzilla well categorized. I would also like to see a "blockers for 1.0" metabug, which I would *very* much like to contain the "window painting in wine" metabug :-).. Then again, I may be way off, I'm totally newbie.
On Mon, 10 Oct 2005, Molle Bestefich wrote:
Richard Cohen wrote:
Metabugs are generally a bad idea because they are very hard to maintain. What is the point of "Get games working perfectly", and how can it ever be resolved?
Who said it needs to be resolved, ever, or in any kind of near future?
I see metabugs more as a categorization feature. If you want an overview of all games that fail in Wine, go check out that particular entry.
Maybe this could be better done with the use of keywords. for instance we could have a 'game' keyword. Then one would find all these bugs by querying for bugs with the 'game' keyword.
I'd like to see metabugs for each DLL or larger area, for instance "Window painting in Wine".
I'm not sure about 'Window painting in Wine', but we could have one keyword per dll. Then once a bug is disgnosed down to a specific dll, the relevant keyword would be added. This would let developpers with specific knowledge of a given dll look for bugs in their domain. This would also make the keyword list more intuitive and simpler to maintain. One issue with using keywords is that currently it seems one needs special privileges to set them. But this is more a policy issue than a technical one and it can probably be resolved quite easily. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
On 10/10/05, Francois Gouget <fgouget(a)free.fr> wrote:
I'd like to see metabugs for each DLL or larger area, for instance "Window painting in Wine".
I'm not sure about 'Window painting in Wine', but we could have one keyword per dll. Then once a bug is disgnosed down to a specific dll, the relevant keyword would be added. This would let developpers with specific knowledge of a given dll look for bugs in their domain. This would also make the keyword list more intuitive and simpler to maintain.
I agree we should have a either a keyword per dll or a component per dll. If I decide to work on shell32 bugs, querying bugzilla for shell32 should return all shell32 bugs. Just searching comments or summary doesn't always catch them, because the reporter might not know that shell32 is the cause of the problem. We're pretty close to this system already with components like wine-ole, wine-richedit, wine-shdocvw etc, so taking the extra step would be very benificial. -- James Hawkins
Francois Gouget wrote:
On Mon, 10 Oct 2005, Molle Bestefich wrote:
Richard Cohen wrote:
Metabugs are generally a bad idea because they are very hard to maintain. What is the point of "Get games working perfectly", and how can it ever be resolved?
Who said it needs to be resolved, ever, or in any kind of near future?
I see metabugs more as a categorization feature. If you want an overview of all games that fail in Wine, go check out that particular entry.
I can see adding a game keyword.
Maybe this could be better done with the use of keywords. for instance we could have a 'game' keyword. Then one would find all these bugs by querying for bugs with the 'game' keyword.
I'd like to see metabugs for each DLL or larger area, for instance "Window painting in Wine".
I'm not sure about 'Window painting in Wine', but we could have one keyword per dll. Then once a bug is disgnosed down to a specific dll, the relevant keyword would be added. This would let developpers with specific knowledge of a given dll look for bugs in their domain. This would also make the keyword list more intuitive and simpler to maintain.
Isn't it this what component is for. Currently I know that if it is an MSI bug I set the component to wine-msi and that way Mike McCormack can find them easily. The big difference between keywords and components is each bug can only have one component but many keywords. Bugzilla also has the ability to have component owners but we do not use them so far. Right now the owner of all components is wine-bugs(a)winehq.org so this difference is moot at this time.
One issue with using keywords is that currently it seems one needs special privileges to set them. But this is more a policy issue than a technical one and it can probably be resolved quite easily.
You do not need special rights to set existing keywords in a bug. However adding new keywords is a special function (which not everyone has) and so is adding new components. Anyone who wants a new keyword or component added to bugzilla can contact me and if it is obvious there is a need for it I will add it otherwise I will open a discussion here. Tony Lambregts
On Mon, 10 Oct 2005, Tony Lambregts wrote: [...]
I'm not sure about 'Window painting in Wine', but we could have one keyword per dll. Then once a bug is disgnosed down to a specific dll, the relevant keyword would be added. This would let developpers with specific knowledge of a given dll look for bugs in their domain. This would also make the keyword list more intuitive and simpler to maintain.
Isn't it this what component is for. Currently I know that if it is an MSI bug I set the component to wine-msi and that way Mike McCormack can find them easily.
Yes, you're right of course. I had forgotten about 'components'.
The big difference between keywords and components is each bug can only have one component but many keywords.
Yes, but each bug probably corresponds to only one component so that should be ok. Then there's the granularity issue, i.e. currently there is not a one to one mapping between dlls and components. IIRC the rationale was that having one component per dll was too fine grained and that users would not know what component to put. But I would argue that most of the time users have no idea what component to put anyway. They're prone to take their cue from the first trace in the log and select the component based on that even though the bug is in fact a stack overflow for instance, and thus completely unrelated. So IMHO we have to rely on our Bugzilla maintainers to assign meaningful components to bugs anyway and then they would know exactly which one to use. But then having exactly one component per dll means a RichEdit specialist would have to query for riched32 or richedit20, a network specialist for wsock32, ws2_32 or winsock, etc. So maybe having one component per dll is too fine grained after all. But then in the latter example does the 'wine-net' component include wininet or not? It's the kind of ambiguity that having one component per dll would avoid. Also it would make remembering the component names easier (is it network, wine-net, wine-network?), though I admit that with a list to pick from this point is probably moot. So these are my thoughts and they probably don't help very much<g>.
One issue with using keywords is that currently it seems one needs special privileges to set them. But this is more a policy issue than a technical one and it can probably be resolved quite easily.
You do not need special rights to set existing keywords in a bug. However adding new keywords is a special function (which not everyone has) and so is adding new components.
Ok, I was wrong then. That sounds perfect. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
Francois Gouget wrote:
On Mon, 10 Oct 2005, Tony Lambregts wrote: [...]
I'm not sure about 'Window painting in Wine', but we could have one keyword per dll. Then once a bug is disgnosed down to a specific dll, the relevant keyword would be added. This would let developpers with specific knowledge of a given dll look for bugs in their domain. This would also make the keyword list more intuitive and simpler to maintain.
Isn't it this what component is for. Currently I know that if it is an MSI bug I set the component to wine-msi and that way Mike McCormack can find them easily.
Yes, you're right of course. I had forgotten about 'components'.
The big difference between keywords and components is each bug can only have one component but many keywords.
Yes, but each bug probably corresponds to only one component so that should be ok.
Then there's the granularity issue, i.e. currently there is not a one to one mapping between dlls and components. IIRC the rationale was that having one component per dll was too fine grained and that users would not know what component to put. But I would argue that most of the time users have no idea what component to put anyway. They're prone to take their cue from the first trace in the log and select the component based on that even though the bug is in fact a stack overflow for instance, and thus completely unrelated. So IMHO we have to rely on our Bugzilla maintainers to assign meaningful components to bugs anyway and then they would know exactly which one to use.
But then having exactly one component per dll means a RichEdit specialist would have to query for riched32 or richedit20, a network specialist for wsock32, ws2_32 or winsock, etc. So maybe having one component per dll is too fine grained after all. But then in the latter example does the 'wine-net' component include wininet or not? It's the kind of ambiguity that having one component per dll would avoid. Also it would make remembering the component names easier (is it network, wine-net, wine-network?), though I admit that with a list to pick from this point is probably moot.
So these are my thoughts and they probably don't help very much<g>.
Well listing the dlls involved with each commponent in the description at least would be an idea . This is the list of components we currently have: test Test Component wine-binary Low level environment, thunking, calling conventions, addressing wine-console Console mode, TTY driver wine-debug Builtin debugger, trace messages, debugging interface wine-directx Obsolete (Use individualized components) wine-directx-d3d New DirectX code >= dx8 wine-directx-ddraw Old DirectX code < dx8 wine-directx-dinput DirectX DInput wine-directx-dmusic DirectX Music wine-directx-dplay DirectX DPlay wine-directx-dshow Direct X DShow wine-directx-dsound DirectX sound wine-documentation Wine documentation wine-dos DOS support, INT n calls wine-files Filesystem interaction wine-gdi-(printing) Drawing, graphics, fonts, drivers wine-gui Controls, dialogs, shell wine-help Basic support or configuration request wine-ipc Communication between Wine processes or app tasks/processes/threads wine-kernel Memory management, tasks, processes and threads, synchronization, exception handling, VxD drivers wine-loader The NE, PE and MZ program loaders wine-misc Unknown, uncategorized, or app-specific problem wine-msi Microsoft Installer wine-multimedia MCI; Audio (wave, mciwave, msacm, midi) and video (vfw, mciavi); mixer, timers, and joystick wine-net Networking, winsock wine-ole OLE, Active X wine-patches Report consisting solely of a patch wine-ports OS specific issues, portability, hardware emulation wine-programs Winelib programs shipped with Wine wine-resources Wrc, resource handling, faulty system resources wine-richedit bugs with richedit control wine-shdocvw Shell Doc Object and Control Library (internet browser interface for basic file and networking operations) wine-tools Subsidiary tools (except wrc) wine-user Events, messages, window handling wine-winelib Winelib issues wine-x11driver Bugs about problems with Wine X11 driver. and these are the directories we have under dlls activeds advapi32 advpack amstream atl avicap32 avifil32 cabinet capi2032 cards, cfgmgr32 comcat comctl32 commdlg crtdll crypt32 cryptdll ctl3d d3d8 d3d9 d3dim d3drm d3dx8 d3dxof dbghelp dciman32 ddraw devenum dinput dinput8 dmband, dmcompos dmime dmloader dmscript dmstyle dmsynth dmusic dmusic32 dplay dplayx dpnet dpnhpast dsound dswave dxdiagn dxerr8 dxerr9 dxguid gdi glu32 glut32 iccvid icmp ifsmgr.vxd imagehlp imm32 iphlpapi itss kernel lzexpand mapi32 mciavi32 mcicda mciseq midimap mlang mpr msacm mscms msdmo mshtml msi msimg32 msisys msnet32 msrle32 msvcrt msvcrt20 msvcrt40 msvcrtd msvidc32 msvideo mswsock msxml3 netapi32 newdev ntdll objsel odbc32 odbccp32 ole32 oleacc oleaut32 olecli oledlg olepro32 olesvr opengl32 powrprof psapi qcap quartz rasapi32 riched20 richedit rpcrt4 rsabase rsaenh secur32 sensapi, serialui setupapi shdocvw shell32 shfolder shlwapi snmpapi sti strmiids tapi32 ttydrv twain unicows url urlmon user usp10 uuid uxtheme vdmdbg version win32s winaspi, winecrt0 wined3d winedos wineps wininet winmm winnls winsock winspool wintab32 wintrust wldap32 wow32 wsock32 wtsapi32 x11drv I can try to list the correct dll under each category but I am going to need som help somewhere along the line. Some are obvious to me but others make my head hum... If it is worth while I am certainly willing to do it. -- Tony Lambregts.
On 10/12/05, Tony Lambregts <tony.lambregts(a)gmail.com> wrote:
I can try to list the correct dll under each category but I am going to need som help somewhere along the line. Some are obvious to me but others make my head hum...
If it is worth while I am certainly willing to do it.
I think what Francois and I were proposing is one component (or keyword) per dll for finer-grained control. I don't think it would be very useful to list the dlls under the categories we have already, because the categories are too broad, though I do appreciate the effort you are putting into it. -- James Hawkins
Francois Gouget wrote:
Molle Bestefich wrote:
Richard Cohen wrote:
Metabugs are generally a bad idea because they are very hard to maintain. What is the point of "Get games working perfectly", and how can it ever be resolved?
Who said it needs to be resolved, ever, or in any kind of near future?
I see metabugs more as a categorization feature. If you want an overview of all games that fail in Wine, go check out that particular entry.
Maybe this could be better done with the use of keywords. for instance we could have a 'game' keyword. Then one would find all these bugs by querying for bugs with the 'game' keyword.
Honestly, I think metabugs are better than keywords. It's mainly a user interface thing. Freetext keywords seem like this really weird feature, which is not clearly represented in the UI, and where the consequences of entering a particular keyword is not especially clear. I think that noone likes to use it (feel free to correct me). Metabugs are much more clear. There's a descriptive text and discussion page for the metabug, where people can discuss which bugs really belong there, or whether this and that bug is related, or which bugs are most critical and needs to be prioritized. Keywords are also prone to spelling mistakes. Enter "shell23" instead of "shell32", noone will find the bug. Metabugs are more "set in stone", you just have to find the right bug id. Not a big problem per se, but might prevent people from wanting to use it.
On Tue, 11 Oct 2005, Molle Bestefich wrote: [...]
It's mainly a user interface thing. Freetext keywords seem like this really weird feature, which is not clearly represented in the UI, and where the consequences of entering a particular keyword is not especially clear. I think that noone likes to use it (feel free to correct me).
I don't share your aversion for keywords. As for them not being clearly represented in the GUI, at least when a bug has a keyword, the keyword is clearly visible in the 'Keywords:' field, whereas when it is associated to a meta-bug all you see is a cryptic dependency on bug 967 or some such. Also the Bugzilla keywords are not freetext. More on this below.
Metabugs are much more clear. There's a descriptive text and discussion page for the metabug, where people can discuss which bugs really belong there, or whether this and that bug is related, or which bugs are most critical and needs to be prioritized.
There is a page which describes each keyword. To get to it simply click on the 'Keywords:' label in any bug: http://bugs.winehq.org/describekeywords.cgi Note: On this page you can see how many bugs are related to each keyword. Simply click on the bug count and you get all the bugs for that keyword.
Keywords are also prone to spelling mistakes. Enter "shell23" instead of "shell32", noone will find the bug.
No. As I said above the Bugzilla keywords are not freetext. Type 'shell23' and all you will get is the following error message: (on a violently red background to be sure you notice it<g>) shell23 is not a known keyword. The legal keyword names are listed here. Metabugs on the other hand are prone to typos. Say I type '976' instead of '967', Bugzilla won't issue an error message. And if I don't follow the link to make sure I typed right I will not notice the mistake. As you mentioned such a simple typo will prevent people from finding the bug. And since components might be a better match than keywords for some tasks, I will just mention that like keywords they are not freetext, they are clearly displayed in the GUI, and have a page describing them (http://bugs.winehq.org/describecomponents.cgi?product=Wine). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong
Francois Gouget wrote: [...] Thanks for the clarifications ;)!
There is a page which describes each keyword. To get to it simply click on the 'Keywords:' label in any bug:
Well, there I go. That page was well hidden from public view. I see now that it's linked from the <keywords> anchor on a bug. That's a bit weird, since half of those anchors just link to static informational pages with dumb content. Would've been nice if those had a 'help' icon, to discern them from those that are actually useful. Or perhaps the 'keywords' and 'components' pages should be added to the Bugzilla menu over to the left. My amazement over how unintuitive Bugzilla is will never cease :-).
Am Dienstag, den 11.10.2005, 12:48 +0200 schrieb Francois Gouget:
And since components might be a better match than keywords for some tasks, I will just mention that like keywords they are not freetext, they are clearly displayed in the GUI, and have a page describing them (http://bugs.winehq.org/describecomponents.cgi?product=Wine).
I suggested to add "wine-printing" in #3302 ( http://bugs.winehq.org/show_bug.cgi?id=3302 ) I think, printing is very important for wine, how many users know, that printing is a part of "wine-gdi" and the subject is less specific than other keywords ("wine-richedit" as example). What do you all think about this topic? -- By By ... ... Detlef
Detlef Riekenberg wrote:
Am Dienstag, den 11.10.2005, 12:48 +0200 schrieb Francois Gouget:
And since components might be a better match than keywords for some tasks, I will just mention that like keywords they are not freetext, they are clearly displayed in the GUI, and have a page describing them (http://bugs.winehq.org/describecomponents.cgi?product=Wine).
I suggested to add "wine-printing" in #3302 ( http://bugs.winehq.org/show_bug.cgi?id=3302 )
I think, printing is very important for wine, how many users know, that printing is a part of "wine-gdi" and the subject is less specific than other keywords ("wine-richedit" as example).
What do you all think about this topic?
I changed wine-gdi to read wine-gdi-(printing) This makes it more obvious to everyone. I could change it to something else if anyone has a better idea. -- Tony Lambregts
On Mon, 10 Oct 2005 08:45:30 +0200, James Hawkins <truiken(a)gmail.com> wrote:
Hi,
I really appreciate the effort everyone has put into cleaning out the old bugs in our bugzilla recently; however, I do have an issue with the way we're closing some of the bug reports. The ultimate outcome of wine is to enable a user to run windows apps just as they would in windows, so if a user has to run the app with a native dll or follow special instructions to make it work, then there is a bug in wine that needs to be fixed. Quite a few bugs have been closed recently referring the user to the instructions in the AppDB or to a list of dll overrides that makes the app work. Recommending a dll override can be useful to the end user as a temporary workaround, but the bug hasn't been fixed. Cleaning out the bugzilla is well appreciated, but we must keep up due diligence in order to keep wine's bugzilla as a reliable status of wine's bugs. I offer this as the beginning of a discussion of bugzilla administration policies. Any thoughts, comments, and ideas are welcome.
-- James Hawkins
That was basically the point I was trying to make in the autocleaning script thread but I got told if I didnot like it I should volenteer as bugzilla maintainer. I dont really give a hoot if wine bugzilla gets scapped, I was just trying to make the suggestion that the wish to reduce truely dead bugs should not be done in a way that reduces the value of the bug database and wastes the efforts of those have taken the time to fill a bug report. I'm going to clear up my garage later but I'm not going to be throwing out the spanners to make the workshop look tidier. Maybe you expressed it a bit better. ;)
participants (8)
-
Dan Kegel -
Detlef Riekenberg -
Francois Gouget -
James Hawkins -
Molle Bestefich -
Richard Cohen -
Tony Lambregts -
wino＠piments.com