Please add these new components:
wine-vdm - Wine 16-bit compatibility layer wine-comdlg - Common dialogs such as open/save/print/font
Vitaliy.
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
Please add these new components:
wine-vdm - Wine 16-bit compatibility layer wine-comdlg - Common dialogs such as open/save/print/font
(it either should be wine-commdlg, or wine-comdlg32 IMO)
What's happened to the proposal to remove the wine- prefix from bugzilla components and have the components represent the dlls they belong to?
Dmitry Timoshkov wrote:
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
Please add these new components:
wine-vdm - Wine 16-bit compatibility layer wine-comdlg - Common dialogs such as open/save/print/font
(it either should be wine-commdlg, or wine-comdlg32 IMO)
Doesn't matter they all uniquely identify the part of Wine. I'd like to have "comdlg" - it corresponds to the dll name without "32" part.
What's happened to the proposal to remove the wine- prefix from bugzilla components and have the components represent the dlls they belong to?
This would be really nice, however not sure how much work will it take. Don't think bugzilla supports renaming of the components. Might need some custom converter.
Vitaliy
For me with this renaming is important that at least from the description it should then be absolutely clear what goes into a component and what not (for a developer).
On Sat, Dec 15, 2007 at 09:27:52PM -0700, Vitaliy Margolen wrote:
What's happened to the proposal to remove the wine- prefix from bugzilla components and have the components represent the dlls they belong to?
I didn't want to remove the wine- prefix without also getting most of the other wanted changes done in the same go. But those require that someone gets a list of the exact changes posted and agreed upon on. I didn't have time for that yet... but if none of the other admins get it done I can probably find the time to make the changes in such a list.
I think such a list would need: old name (empty for new components); new name; description (should list other names that are associated with the component or things contained in the component, list of source files that this component contains with bash style globs).
We can also change the default assignee (currently wine-bugs@winehq.org for all components) and/or default cc list (AFAIK currently empty for all components).
Possibly bad example: wine-directx-dshow; directx-dshow; DirectShow ( dlls/{quartz,msdmo,qcap}/ ); dshow-hacker@test.test; dshowhacker2@test.test, dhowhacker3@test.text;
If we want to move all the bugs from one component to other components we can delete the component after it doesn't contain any bugs anymore:
wine-foo; deprecated-foo; Bugs in this component should be moved to bar or misc.
This would be really nice, however not sure how much work will it take. Don't think bugzilla supports renaming of the components. Might need some custom converter.
Bugzilla supports renaming components.
Jan
On Dec 16, 2007 6:20 AM, Jan Zerebecki jan.wine@zerebecki.de wrote:
For me with this renaming is important that at least from the description it should then be absolutely clear what goes into a component and what not (for a developer).
On Sat, Dec 15, 2007 at 09:27:52PM -0700, Vitaliy Margolen wrote:
What's happened to the proposal to remove the wine- prefix from bugzilla components and have the components represent the dlls they belong to?
I didn't want to remove the wine- prefix without also getting most of the other wanted changes done in the same go. But those require that someone gets a list of the exact changes posted and agreed upon on. I didn't have time for that yet... but if none of the other admins get it done I can probably find the time to make the changes in such a list.
I think such a list would need: old name (empty for new components); new name; description (should list other names that are associated with the component or things contained in the component, list of source files that this component contains with bash style globs).
We can also change the default assignee (currently wine-bugs@winehq.org for all components) and/or default cc list (AFAIK currently empty for all components).
Possibly bad example: wine-directx-dshow; directx-dshow; DirectShow ( dlls/{quartz,msdmo,qcap}/ ); dshow-hacker@test.test; dshowhacker2@test.test, dhowhacker3@test.text;
If we want to move all the bugs from one component to other components we can delete the component after it doesn't contain any bugs anymore:
wine-foo; deprecated-foo; Bugs in this component should be moved to bar or misc.
This would be really nice, however not sure how much work will it take. Don't think bugzilla supports renaming of the components. Might need some custom converter.
Bugzilla supports renaming components.
Ok, I'll start off the list. This is a first draft, open to changes and discussion. Entries with a (?) means I'm not sure.
Components:
test -> wine-advapi32 -> advapi32 wine-atl -> atl wine-binary -> wine-comctl32 -> comctl32 wine-console -> console (?) wine-crypt32 -> crypt32 wine-dbghelp -> dbghelp wine-debug -> wine-directx* -> directx* (?) wine-documentation -> documentation wine-dos -> dos wine-dotnet -> (?) I have a feeling this should be a keyword wine-files -> wine-gdi-(printing) -> wine-gdi32 wine-gdiplus -> gdiplus wine-gui -> wine-help -> hhctrl. the remaining wine-help bugs should be user32 if they're not hhctrl. wine-ipc -> wine-kernel -> kernel32 wine-loader ->loader wine-misc -> misc or default wine-msi -> msi wine-msvcrt -> msvcrt wine-msxml -> msxml(3) wine-multimedia -> wine-net -> wine-ole -> ole wine-opengl -> opengl keyword (?) wine-patches -> wine-ports -> wine-programs -> programs (might want to keep it wine-programs to not confuse users) wine-quartz -> quartz Wine-Rebar -> bugs moved to comctl32 wine-resources -> wine-richedit -> richedit wine-setupapi -> setupapi wine-shdocvw -> shdocvw wine-shell32 -> shell32 wine-sspi -> (?) I prefer individual modules with a security or sspi keyword, but it's not up to me wine-tools -> (?) wine-urlmon -> urlmon wine-user -> user32 wine-usp10.dll -> usp10 wine-winelib -> wine-x11driver -> x11driver -> wininet -> wintrust -> secur32 -> advpack -> hhctrl -> imagehlp -> shlwapi
On Sunday 16 December 2007 21:14:16 James Hawkins wrote:
Ok, I'll start off the list. This is a first draft, open to changes and discussion. Entries with a (?) means I'm not sure.
Components:
[...]
wine-net ->
If you delete that one, we definitely need a "winsock" component. Or ws2_32... or wsock.. I prefer "winsock" as that matches the debug channel as well.
[...]
wine-sspi -> (?) I prefer individual modules with a security or sspi keyword, but it's not up to me
[...]
-> secur32
Coming to think about that, if we're fine to add more categories for things like secur32.dll, how about splitting up those by debug channel? E.g. my ntlm provider has an "ntlm" debug channel, the kerberos provider that I keep starting and restarting in some branches on my box always uses "kerberos", and Juan might want to use schannel as debug channel.
That would also help advanced users to correctly file bugs according to fixmes, e.g. if they run into an unimplemented function.
Cheers, Kai
On Dec 16, 2007 3:37 PM, Kai Blin kai.blin@gmail.com wrote:
On Sunday 16 December 2007 21:14:16 James Hawkins wrote:
Ok, I'll start off the list. This is a first draft, open to changes and discussion. Entries with a (?) means I'm not sure.
Components:
[...]
wine-net ->
If you delete that one, we definitely need a "winsock" component. Or ws2_32... or wsock.. I prefer "winsock" as that matches the debug channel as well.
ws2_32 or wsock32, or both, depending on the existing bugs.
[...]
wine-sspi -> (?) I prefer individual modules with a security or sspi keyword, but it's not up to me
[...]
-> secur32
Coming to think about that, if we're fine to add more categories for things like secur32.dll, how about splitting up those by debug channel? E.g. my ntlm provider has an "ntlm" debug channel, the kerberos provider that I keep starting and restarting in some branches on my box always uses "kerberos", and Juan might want to use schannel as debug channel.
That would also help advanced users to correctly file bugs according to fixmes, e.g. if they run into an unimplemented function.
I have to voice my disagreement on this one. per-debug channel is too fine-grained, and that's a road we don't want to go down. Think of it like this: the components are not meant to help the users in any way, only the developers. As a developer, will the different provider components (ntlm, kerberos, et.al.) help you any? You'll have to read the logs anyway. schannel, on the other hand, is a module in the wine tree, so that would be a useful component.
On Sunday 16 December 2007 22:47:23 James Hawkins wrote:
ws2_32 or wsock32, or both, depending on the existing bugs.
Given that wsock32 forwards over 90% of the calls to ws2_32, let's go for that one then.
Coming to think about that, if we're fine to add more categories for things like secur32.dll, how about splitting up those by debug channel? E.g. my ntlm provider has an "ntlm" debug channel, the kerberos provider that I keep starting and restarting in some branches on my box always uses "kerberos", and Juan might want to use schannel as debug channel.
I have to voice my disagreement on this one. per-debug channel is too fine-grained, and that's a road we don't want to go down. Think of it like this: the components are not meant to help the users in any way, only the developers.
But I as a part-time developer can't keep track of all the areas in Wine. I don't know anything about.. say GUI.. or actually anything that's not secur32 or maybe winsock. Where's the advantage of me refiling a bug someone filed as.. say "ws2_32" to "default" again because I don't know what gui component is responsible as opposed to me refiling it as wine-gui (see bug 9771 as a specific example that just came up).
As a developer, will the different provider components (ntlm, kerberos, et.al.) help you any? You'll have to read the logs anyway.
Well, maybe. Once schannel is implemented, I probably won't look at those because I don't know about schannel. I don't get your point about having to read logs, because I think that is needed for all but the most obviously invalid bugs.
schannel, on the other hand, is a module in the wine tree, so that would be a useful component.
Nope. It forwards to secur32.dll, apart from two calls. I'm kind of certain we're just arguing about what color the bikeshed should be painted in, but either we just lump all sspi errors into one category, or we have one per logical module.
So I guess the real question is how much diversity we want and need.
Cheers, Kai
On Dec 16, 2007 4:08 PM, Kai Blin kai.blin@gmail.com wrote:
On Sunday 16 December 2007 22:47:23 James Hawkins wrote:
ws2_32 or wsock32, or both, depending on the existing bugs.
Given that wsock32 forwards over 90% of the calls to ws2_32, let's go for that one then.
Coming to think about that, if we're fine to add more categories for things like secur32.dll, how about splitting up those by debug channel? E.g. my ntlm provider has an "ntlm" debug channel, the kerberos provider that I keep starting and restarting in some branches on my box always uses "kerberos", and Juan might want to use schannel as debug channel.
I have to voice my disagreement on this one. per-debug channel is too fine-grained, and that's a road we don't want to go down. Think of it like this: the components are not meant to help the users in any way, only the developers.
But I as a part-time developer can't keep track of all the areas in Wine. I don't know anything about.. say GUI.. or actually anything that's not secur32 or maybe winsock. Where's the advantage of me refiling a bug someone filed as.. say "ws2_32" to "default" again because I don't know what gui component is responsible as opposed to me refiling it as wine-gui (see bug 9771 as a specific example that just came up).
You refile it as misc/default so another developer who is more familiar with the correct component can set the right component. We're getting rid of wine-gui because wine-gui doesn't mean anything...the bug description alone is enough to know that it's a gui bug.
As a developer, will the different provider components (ntlm, kerberos, et.al.) help you any? You'll have to read the logs anyway.
Well, maybe. Once schannel is implemented, I probably won't look at those because I don't know about schannel. I don't get your point about having to read logs, because I think that is needed for all but the most obviously invalid bugs.
You said an advanced user could read the logs and set the provider component based on the fixme's in the logs, and I'm saying that you'll have to read the logs anyway, so the one advantage of that method is taken away.
schannel, on the other hand, is a module in the wine tree, so that would be a useful component.
Nope. It forwards to secur32.dll, apart from two calls. I'm kind of certain we're just arguing about what color the bikeshed should be painted in, but either we just lump all sspi errors into one category, or we have one per logical module.
I have no idea about secur32, schannel, etc. If schannel just forwards to secur32, then there's no need for an schannel component, and any bugs of that nature should be marked as secur32. That still doesn't mean we need an sspi component.
So I guess the real question is how much diversity we want and need.
If most of the functionality is in secur32, where's the need for sspi, and if there's more functionality in other modules besides secur32, then there should be a component for each module that has a reported bug. Like I said before, I don't mind an sspi keyword.
On Dec 15, 2007 10:19 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
Please add these new components:
wine-vdm - Wine 16-bit compatibility layer wine-comdlg - Common dialogs such as open/save/print/font
(it either should be wine-commdlg, or wine-comdlg32 IMO)
What's happened to the proposal to remove the wine- prefix from bugzilla components and have the components represent the dlls they belong to?
Yes, can someone with sufficient privileges enact what was agreed upon by the majority in this thread:
http://www.winehq.org/pipermail/wine-devel/2007-October/059715.html
To summarize:
* Change all wine-X components to just X. * Remove the following components: - wine-rebar - wine-gui - wine-multimedia - wine-net - wine-patches - test
Any bug report listed under the components that are removed would have to be set to wine-misc and eventually relabeled to the correct component (which might need to be added). I'm not a web guy, so I don't know how this would be done, but it would certainly be appreciated.
Thanks, James Hawkins
"James Hawkins" truiken@gmail.com wrote:
Yes, can someone with sufficient privileges enact what was agreed upon by the majority in this thread:
http://www.winehq.org/pipermail/wine-devel/2007-October/059715.html
To summarize:
- Change all wine-X components to just X.
- Remove the following components:
- wine-rebar
- wine-gui
- wine-multimedia
- wine-net
- wine-patches
- test
Also remove wine-binary, wine-debug, wine-files, wine-gdi (printing), wine-gui, wine-ipc, wine-net, wine-patches, wine-ports, wine-resources, wine-winelib
Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32, wine-user -> user32
Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component.
On Dec 15, 2007 10:45 PM, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"James Hawkins" truiken@gmail.com wrote:
Yes, can someone with sufficient privileges enact what was agreed upon by the majority in this thread:
http://www.winehq.org/pipermail/wine-devel/2007-October/059715.html
To summarize:
- Change all wine-X components to just X.
- Remove the following components:
- wine-rebar
- wine-gui
- wine-multimedia
- wine-net
- wine-patches
- test
Also remove wine-binary, wine-debug, wine-files, wine-gdi (printing), wine-gui, wine-ipc, wine-net, wine-patches, wine-ports, wine-resources, wine-winelib
Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32, wine-user -> user32
Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component.
And if there are objections to this approach, I'd like to remind all that we decided to use keywords for generic identification, like we've successfully done with the Installer keyword.
Dmitry Timoshkov wrote:
Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32, wine-user -> user32
Why do you want "32" at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else.
Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component.
No, please do not add all dlls, listed are fine. That will create huge clutter. Lets do it one at a time, whenever we need it.
On Dec 15, 2007 11:02 PM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Dmitry Timoshkov wrote:
Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32, wine-user -> user32
Why do you want "32" at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else.
It's consistent with the policy: one component per module reported. What do you have against the 32? As opengl32 is a thunk, there shouldn't be any bug reports attributed to that component, and the component shouldn't exist. I'm fine with an opengl keyword if people want it, but as you said, the bug lies elsewhere.
Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component.
No, please do not add all dlls, listed are fine. That will create huge clutter. Lets do it one at a time, whenever we need it.
I'm fine with waiting for the report to add components, but there are bug reports now that need components that do not exist.
James Hawkins wrote:
On Dec 15, 2007 11:02 PM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Dmitry Timoshkov wrote:
Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32, wine-user -> user32
Why do you want "32" at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else.
It's consistent with the policy: one component per module reported. What do you have against the 32? As opengl32 is a thunk, there shouldn't be any bug reports attributed to that component, and the component shouldn't exist. I'm fine with an opengl keyword if people want it, but as you said, the bug lies elsewhere.
Assigning openGL bugs to user32 or gdi32 doesn't make it any more clear where the problem is. Because in most case that would be somewhere between x11drv, gdi32, user32. There are lots of examples like that all over the place. Don't forget who designed all this... hm not even sure there was any designs actually. Hard assigning bugs to the dll won't make it any better then too generic categories like we have now.
Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component.
No, please do not add all dlls, listed are fine. That will create huge clutter. Lets do it one at a time, whenever we need it.
I'm fine with waiting for the report to add components, but there are bug reports now that need components that do not exist.
Then please list them.
On Dec 15, 2007 11:27 PM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
James Hawkins wrote:
On Dec 15, 2007 11:02 PM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
Dmitry Timoshkov wrote:
Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32, wine-user -> user32
Why do you want "32" at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else.
It's consistent with the policy: one component per module reported. What do you have against the 32? As opengl32 is a thunk, there shouldn't be any bug reports attributed to that component, and the component shouldn't exist. I'm fine with an opengl keyword if people want it, but as you said, the bug lies elsewhere.
Assigning openGL bugs to user32 or gdi32 doesn't make it any more clear where the problem is. Because in most case that would be somewhere between x11drv, gdi32, user32. There are lots of examples like that all over the place. Don't forget who designed all this... hm not even sure there was any designs actually. Hard assigning bugs to the dll won't make it any better then too generic categories like we have now.
Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL component.
No, please do not add all dlls, listed are fine. That will create huge clutter. Lets do it one at a time, whenever we need it.
I'm fine with waiting for the report to add components, but there are bug reports now that need components that do not exist.
Then please list them.
As Dmitry already said: ntdl, oleaut32, rpcrt4. Searching through bugzilla: wininet, wintrust, secur32, advpack, hhctrl, imagehlp, mshtml, shlwapi, urlmon. There are probably more, but that's a good starter list.
On Sunday 16 December 2007 07:08:57 James Hawkins wrote:
As Dmitry already said: ntdl, oleaut32, rpcrt4. Searching through bugzilla: wininet, wintrust, secur32, advpack, hhctrl, imagehlp, mshtml, shlwapi, urlmon. There are probably more, but that's a good starter list.
There's a category for secur32, called wine-sspi for now. As Microsoft calls the whole GSSAPI clone implemented in secur32 and possibly additional dlls SSPI, it makes sense to call the bugzilla component that way.
Cheers, Kai
"Kai Blin" kai.blin@gmail.com wrote:
There's a category for secur32, called wine-sspi for now. As Microsoft calls the whole GSSAPI clone implemented in secur32 and possibly additional dlls SSPI, it makes sense to call the bugzilla component that way.
sspi consists of at least a host and many security provider dlls, which by itself tells nothing to a user, or a developer who tries to fix a bug where to look for a problem: all of the sspi dlls? some specific dll, provider? somewhere else?
On Sunday 16 December 2007 11:18:11 Dmitry Timoshkov wrote:
"Kai Blin" kai.blin@gmail.com wrote:
There's a category for secur32, called wine-sspi for now. As Microsoft calls the whole GSSAPI clone implemented in secur32 and possibly additional dlls SSPI, it makes sense to call the bugzilla component that way.
sspi consists of at least a host and many security provider dlls, which by itself tells nothing to a user, or a developer who tries to fix a bug where to look for a problem: all of the sspi dlls? some specific dll, provider? somewhere else?
IIRC there are five providers that Win2k and WinXP ship, all of them implemented in secur32.dll. I don't see how renaming the component will create less confusion for the developers.
However, I'm not feeling strong enough about this to really care. If the wine- prefix is removed, I need to adapt my email filters anyway. :)
Cheers, Kai
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32, wine-user -> user32
Why do you want "32" at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else.
If the component exists it should be named properly, i.e. represent the DLL it belongs to in order to avoid a possible confusion.
Dmitry Timoshkov wrote:
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32, wine-user -> user32
Why do you want "32" at the end? Also note that opengl32 is a thunk dll. Most of it's code somewhere else.
If the component exists it should be named properly, i.e. represent the DLL it belongs to in order to avoid a possible confusion.
That's the part I'd like to avoid. Unless we want to list most of the subsystems in keywords, that span small parts of multiple dlls.
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
If the component exists it should be named properly, i.e. represent the DLL it belongs to in order to avoid a possible confusion.
That's the part I'd like to avoid. Unless we want to list most of the subsystems in keywords, that span small parts of multiple dlls.
In the vast majority of cases a bug belongs to a particular DLL, not a group of DLLs, in very rare cases the keywords are supposed to help with identification of the component.
On So, 2007-12-16 at 13:46 +0800, Dmitry Timoshkov wrote:
"Vitaliy Margolen" wine-devel@kievinfo.com wrote:
Unless we want to list most of the subsystems in keywords, that span small parts of multiple dlls.
In the vast majority of cases a bug belongs to a particular DLL, not a group of DLLs, in very rare cases the keywords are supposed to help with identification of the component.
One of the needed keywords is printing. I asked for a seperate component years ago, but only got "wine-gdi" renamed to "wine-gdi-(printing)".
Printing is also a part of gdi, but printing is much more than gdi. (wineps.drv and winspool.drv are the big visible parts).
Dmitry Timoshkov wrote:
Rename wine-ole -> ole32
Add oleaut32, rpcrt4
Currently, all of the above are filed in wine-ole and I don't have a problem with that. Since a common question by our bugzilla advocates is "does installing DCOM fix the bug?" then this makes sense.
Care needs to be taken with creating other categories too so that any new categories you create are useful to the developers that work on that area and to the people who triage bugs. (For example, consult Jacek before creating separate mshtml, shdocvw and urlmon components.)
Robert Shearman wrote:
(For example, consult Jacek before creating separate mshtml, shdocvw and urlmon components.)
We currently have wine-shdocvw and wine-urlmon. That's fine for me and I don't think we want to split shdocvw to mshtml and shdocvw. Although the current name may be confusing (I don't really care about the name), it's often not obvious which of these DLLs has caused the bug (it will be even worse when we will move part of shdocvw.dll to ieframe.dll, as IE7 did).
Jacek
On Sunday 16 December 2007 05:34:18 James Hawkins wrote:
- Remove the following components:
- wine-rebar
- wine-gui
- wine-multimedia
- wine-net
- wine-patches
- test
Any bug report listed under the components that are removed would have to be set to wine-misc and eventually relabeled to the correct component (which might need to be added). I'm not a web guy, so I don't know how this would be done, but it would certainly be appreciated.
Is there an inherent advantage of splitting wine-net into wininet and winsock? (Apart from probably getting less .NET bugs filed in the category? ;) )
I'm not sure if diversifying more than needed will actually help. The time saved by not seeing e.g. wininet reports in the winsock category might be spent reclassifying bugs to the appropriate category. Right now users can just select "wine-net" if there's a problem with networking.
Cheers, Kai
"Kai Blin" kai.blin@gmail.com wrote:
Is there an inherent advantage of splitting wine-net into wininet and winsock? (Apart from probably getting less .NET bugs filed in the category? ;) )
wininet and winsock are two absolutely different layers of very different functionality.
I'm not sure if diversifying more than needed will actually help. The time saved by not seeing e.g. wininet reports in the winsock category might be spent reclassifying bugs to the appropriate category. Right now users can just select "wine-net" if there's a problem with networking.
Users are not supposed to set a category the bug belongs to, this requires an investigation and knowledge of a developer. Personally I'd prefer to have "default" in the list instead of "wine-misc".
-
Detlef Riekenberg -
Dmitry Timoshkov -
Jacek Caban -
James Hawkins -
Jan Zerebecki -
Kai Blin -
Robert Shearman -
Vitaliy Margolen