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.