I agree the wine- prefix should be removed.
Currently we have quite some categories where I don't really know how they are defined, so the description should be enhanced so there is no confusion over what goes in them.
Currently we have some categories that exactly fit to one dll and some categories that include multiple dlls that are related. Also there is overlap between those two. (And perhaps some that fit in neither.)
E.g. there is wine-quartz (one dll dlls/quartz/ ) and wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ).
The best is probably to have no overlap and have multi-dll/path categories contain the shell-glob of path/files that it contains.
I think in some cases multi-dll categories are preferable to single-dlls ones. A even better example for this than dshow is wine-directx-d3d, where before the bug is fixed it might not be easily known if it is in d3d9 or wined3d and a bug might exist in the same way in more than one d3d version.
From previous discussions on irc I know some people want to have
a radical one category per dll approach, please speak up now.
What do you guys think?
Jan
PS: Sorry for the previous empty mail.
Hi Jan,
Jan Zerebecki schreef:
I agree the wine- prefix should be removed.
Currently we have quite some categories where I don't really know how they are defined, so the description should be enhanced so there is no confusion over what goes in them.
Currently we have some categories that exactly fit to one dll and some categories that include multiple dlls that are related. Also there is overlap between those two. (And perhaps some that fit in neither.)
E.g. there is wine-quartz (one dll dlls/quartz/ ) and wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ).
I believe wine-quartz is meant for dlls/winequartz.drv, which is the mac os x quartz driver.
The best is probably to have no overlap and have multi-dll/path categories contain the shell-glob of path/files that it contains.
I think in some cases multi-dll categories are preferable to single-dlls ones. A even better example for this than dshow is wine-directx-d3d, where before the bug is fixed it might not be easily known if it is in d3d9 or wined3d and a bug might exist in the same way in more than one d3d version.
From previous discussions on irc I know some people want to have
a radical one category per dll approach, please speak up now.
I'm against specific dll components, if you report a bug it could be a series of dlls, so something like direct3d would be better then wined3d, d3d9, d3d8, d3d7.
Cheers, Maarten.
On 10/10/07, Jan Zerebecki jan.wine@zerebecki.de wrote:
I agree the wine- prefix should be removed.
Currently we have quite some categories where I don't really know how they are defined, so the description should be enhanced so there is no confusion over what goes in them.
Currently we have some categories that exactly fit to one dll and some categories that include multiple dlls that are related. Also there is overlap between those two. (And perhaps some that fit in neither.)
E.g. there is wine-quartz (one dll dlls/quartz/ ) and wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ).
The best is probably to have no overlap and have multi-dll/path categories contain the shell-glob of path/files that it contains.
I think in some cases multi-dll categories are preferable to single-dlls ones. A even better example for this than dshow is wine-directx-d3d, where before the bug is fixed it might not be easily known if it is in d3d9 or wined3d and a bug might exist in the same way in more than one d3d version.
From previous discussions on irc I know some people want to have a radical one category per dll approach, please speak up now.
What do you guys think?
One component per dll is ideal for development. When we identify what dll a particular bug is in through triage, it helps any other developer that decides to pick up the bug and fix it. wine-gui is a terrible component. gui can mean any number of places to hunt down a bug. It would be great if people could help triage wine-gui bugs and fix the components. Eventually we should be at a point where we can get rid of the wine-gui component. wine-misc is the general place-holder component, and really should be selected as default in bugzilla for new reports. Concerning using one component per dll versus broad/group components, the way we have it now works fine. There are some situations where a group component works best, e.g. directX. In most cases though, per dll is best. We can have both types of components. The following is a list of components that need to get the boot or be renamed:
wine-rebar (this is comctl32, no need for this component) wine-binary (what does that even mean?) wine-gdi-(printing) -> gdi wine-gui (per dll) wine-multimedia (per dll) wine-net (needs to be per dll) wine-patches (what was this for?) wine-user -> user32 wine-usp10.dll -> usp10 bug list, comments, login (what are these for?)
James Hawkins <truiken <at> gmail.com> writes:
Currently we have some categories that exactly fit to one dll and some categories that include multiple dlls that are related. Also there is overlap between those two. (And perhaps some that fit in neither.)
E.g. there is wine-quartz (one dll dlls/quartz/ ) and wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ).
Well, the common (newbie) user probably won't know anything about dshow (neither do i ;) ), nor will he know what quartz stands for. The only thing he will see in his console is something like:
fixme:quartz: blablabla
So for example if he was about to search for duplicates before filing a bug, it's really better to have a per dll component.
One component per dll is ideal for development. There are some situations where a group component works best, e.g. directX. In most cases though, per dll is best. We can have both types of components. The following is a list of components that need to get the boot or be renamed:
wine-rebar (this is comctl32, no need for this component) wine-binary (what does that even mean?) wine-gdi-(printing) -> gdi wine-gui (per dll) wine-multimedia (per dll) wine-net (needs to be per dll) wine-patches (what was this for?) wine-user -> user32 wine-usp10.dll -> usp10 bug list, comments, login (what are these for?)
totally agree with James. I'll await the changes.....
On 10/10/07, Louis Lenders xerox_xerox2000@yahoo.co.uk wrote:
James Hawkins <truiken <at> gmail.com> writes:
Currently we have some categories that exactly fit to one dll and some categories that include multiple dlls that are related. Also there is overlap between those two. (And perhaps some that fit in neither.)
E.g. there is wine-quartz (one dll dlls/quartz/ ) and wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ).
Well, the common (newbie) user probably won't know anything about dshow (neither do i ;) ), nor will he know what quartz stands for.
That's why wine-misc should be selected by default, and honestly it's the responsibility of bugzilla maintainers/triagers to set and fix components if the user doesn't know (which most don't).
On Wed, Oct 10, 2007 at 03:52:36PM -0500, James Hawkins wrote:
On 10/10/07, Louis Lenders xerox_xerox2000@yahoo.co.uk wrote:
E.g. there is wine-quartz (one dll dlls/quartz/ ) and wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ).
Well, the common (newbie) user probably won't know anything about dshow (neither do i ;) ), nor will he know what quartz stands for.
That is why I suggest to add something like dlls/{quartz,msdmo,qcap}/ to the description of the component.
That's why wine-misc should be selected by default, and honestly it's the responsibility of bugzilla maintainers/triagers to set and fix components if the user doesn't know (which most don't).
I agree, in the end we usually need to verify anyway that the component is correct.
Jan
On Mi, 2007-10-10 at 15:20 -0500, James Hawkins wrote:
wine-gdi-(printing) -> gdi
This is a bad Idea. We have a lot of different dlls related to printing:
comdlg32.dll compstui.dll gdi32.dll localspl.dll printui.dll shell32.dll wineps.drv winspool.drv
I vote for "printing" next to "gdi"
On 10/11/07, Detlef Riekenberg wine.dev@web.de wrote:
On Mi, 2007-10-10 at 15:20 -0500, James Hawkins wrote:
wine-gdi-(printing) -> gdi
This is a bad Idea. We have a lot of different dlls related to printing:
comdlg32.dll compstui.dll gdi32.dll localspl.dll printui.dll shell32.dll wineps.drv winspool.drv
I vote for "printing" next to "gdi"
What's wrong with having a new printing component? Lumping *all* gdi/printing bugs into gdi-(printing) is a bad idea.
On 10/11/07, James Hawkins truiken@gmail.com wrote:
On 10/11/07, Detlef Riekenberg wine.dev@web.de wrote:
On Mi, 2007-10-10 at 15:20 -0500, James Hawkins wrote:
wine-gdi-(printing) -> gdi
This is a bad Idea. We have a lot of different dlls related to printing:
comdlg32.dll compstui.dll gdi32.dll localspl.dll printui.dll shell32.dll wineps.drv winspool.drv
I vote for "printing" next to "gdi"
What's wrong with having a new printing component? Lumping *all* gdi/printing bugs into gdi-(printing) is a bad idea.
-- James Hawkins
How about "gdi-printing" and "gdi-video"?
On 10/11/07, Jesse Allen the3dfxdude@gmail.com wrote:
On 10/11/07, James Hawkins truiken@gmail.com wrote:
On 10/11/07, Detlef Riekenberg wine.dev@web.de wrote:
On Mi, 2007-10-10 at 15:20 -0500, James Hawkins wrote:
wine-gdi-(printing) -> gdi
This is a bad Idea. We have a lot of different dlls related to printing:
comdlg32.dll compstui.dll gdi32.dll localspl.dll printui.dll shell32.dll wineps.drv winspool.drv
I vote for "printing" next to "gdi"
What's wrong with having a new printing component? Lumping *all* gdi/printing bugs into gdi-(printing) is a bad idea.
-- James Hawkins
How about "gdi-printing" and "gdi-video"?
No, because not all printing problems are gdi, and if you don't have gdi-printing, there's no need for gdi-video; just plain gdi works. The same argument goes for gdi-video. So, we should have:
gdi printing
and any bugs that are marked as wine-gdi-(printing) should be set to one or the other.
On 10/11/07, James Hawkins truiken@gmail.com wrote:
No, because not all printing problems are gdi, and if you don't have gdi-printing, there's no need for gdi-video; just plain gdi works. The same argument goes for gdi-video. So, we should have:
gdi printing
and any bugs that are marked as wine-gdi-(printing) should be set to one or the other.
Yes I second this motion. The components should be named as simply as possible. Users are going to be the ones filing the reports and whoever is doing triage is going to have to move it around if its in the wrong area. Abstract names like DirectX, Sound, Graphics, Installers and Printing are a much better idea than dllnames. Hell I don't even know what shdocvw does really and when an application starts spewing FIXME messages that have random dllnames in them we are just going to get bad bug reports. Its much better to have abstract categories that match behavioral issues.
On Thu, 11 Oct 2007, Steven Edwards wrote: [...]
gdi printing
[...]
Yes I second this motion. The components should be named as simply as possible. Users are going to be the ones filing the reports and whoever is doing triage is going to have to move it around if its in the wrong area. Abstract names like DirectX, Sound, Graphics, Installers and Printing are a much better idea than dllnames.
[...]
Sounds good to me too. But just for the sake of it, I will mention that we have keywords too.
So we can have broad categories like 'printing' and 'display', and dll-specific keywords like 'gdi32' and 'comctl32'.
Or we can do the opposite and have broad keywords for 'printing' and 'display', and then dll-specific categories.
Or we could stay with the current scheme because both of the above may be abuses of the keyword system.
Up to you.
One more issue to raise: is the reason why we have 'wine-' as the prefix to avoid conflicts between different products? That is, if we have a 'printing' category in the 'Wine' product, is it going to interfer with the 'printing' category of a 'Wine-doc' product?
On 10/12/07, Francois Gouget fgouget@free.fr wrote:
On Thu, 11 Oct 2007, Steven Edwards wrote: [...]
gdi printing
[...]
Yes I second this motion. The components should be named as simply as possible. Users are going to be the ones filing the reports and whoever is doing triage is going to have to move it around if its in the wrong area. Abstract names like DirectX, Sound, Graphics, Installers and Printing are a much better idea than dllnames.
[...]
Sounds good to me too. But just for the sake of it, I will mention that we have keywords too.
So we can have broad categories like 'printing' and 'display', and dll-specific keywords like 'gdi32' and 'comctl32'.
Or we can do the opposite and have broad keywords for 'printing' and 'display', and then dll-specific categories.
Or we could stay with the current scheme because both of the above may be abuses of the keyword system.
Up to you.
Yea that works too. I would actually prefer having them as keywords and keeping components per dll. It's been working great for the installer keyword, where the components are usually, but not limited to, msi, setupapi, advpack.
One more issue to raise: is the reason why we have 'wine-' as the prefix to avoid conflicts between different products? That is, if we have a 'printing' category in the 'Wine' product, is it going to interfer with the 'printing' category of a 'Wine-doc' product?
You'd think bugzilla would be more dynamic. For example, if you choose WineHQ.org as the product, then you only get components available to that product. Unfortunately, I don't think it works that way.
On Fri, Oct 12, 2007 at 11:09:53AM -0500, James Hawkins wrote:
On 10/12/07, Francois Gouget fgouget@free.fr wrote:
On Thu, 11 Oct 2007, Steven Edwards wrote:
One more issue to raise: is the reason why we have 'wine-' as the prefix to avoid conflicts between different products? That is, if we have a 'printing' category in the 'Wine' product, is it going to interfer with the 'printing' category of a 'Wine-doc' product?
You'd think bugzilla would be more dynamic. For example, if you choose WineHQ.org as the product, then you only get components available to that product. Unfortunately, I don't think it works that way.
In bugzilla components are per product (i.e. you can have a printing component in Wine and Wine-doc and they are two different ones).
[...]
gdi printing
[...]
Yes I second this motion. The components should be named as simply as possible. Users are going to be the ones filing the reports and whoever is doing triage is going to have to move it around if its in the wrong area. Abstract names like DirectX, Sound, Graphics, Installers and Printing are a much better idea than dllnames.
[...]
Sounds good to me too. But just for the sake of it, I will mention that we have keywords too.
So we can have broad categories like 'printing' and 'display', and dll-specific keywords like 'gdi32' and 'comctl32'.
Or we can do the opposite and have broad keywords for 'printing' and 'display', and then dll-specific categories.
Or we could stay with the current scheme because both of the above may be abuses of the keyword system.
Up to you.
Yea that works too. I would actually prefer having them as keywords and keeping components per dll. It's been working great for the installer keyword, where the components are usually, but not limited to, msi, setupapi, advpack.
We also have custom fields. (Currently Difficulty is our only one.) So we could e.g. have a field where we would put something like dlls/wined3d/foo.c:bar() to say exactly where the problem is located if that is known.
Jan
On Do, 2007-10-11 at 16:32 -0600, Jesse Allen wrote:
How about "gdi-printing" and "gdi-video"?
No. GDI is more than printing and for printing, you need GDI, but also much more out of GDI
Whe the bug-creator set the component to "printing", we can change it later to the more specific component, when needed (gdi, wineps, spooler, comdlg32 as examples)
On Do, 2007-10-11 at 14:24 -0500, James Hawkins wrote:
wine-gdi-(printing) -> gdi
I vote for "printing" next to "gdi"
What's wrong with having a new printing component?
That was my vote above. I asked for a "printing" component over 1 year ago, but only "wine-gdi" was changes to "wine-gdi-(printing)"
Lumping *all* gdi/printing bugs into gdi-(printing) is a bad idea.
Yes.
-
Detlef Riekenberg -
Francois Gouget -
James Hawkins -
Jan Zerebecki -
Jesse Allen -
Louis Lenders -
Maarten Lankhorst -
Steven Edwards