Bugzilla administration policies
tony.lambregts at gmail.com
Wed Oct 12 19:00:53 CDT 2005
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
test Test Component
wine-binary Low level environment, thunking, calling
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
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
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.
More information about the wine-devel