Bugzilla administration policies

[Tony Lambregts]

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.