Re: defining and revamping our bugzilla categories
On Fri, Oct 12, 2007 at 11:09:53AM -0500, James Hawkins wrote: > On 10/12/07, Francois Gouget <[EMAIL PROTECTED]> 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
Re: defining and revamping our bugzilla categories
On 10/12/07, Francois Gouget <[EMAIL PROTECTED]> 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. -- James Hawkins
Re: defining and revamping our bugzilla categories
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) -- By by ... Detlef
Re: defining and revamping our bugzilla categories
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. -- By by ... Detlef
Re: defining and revamping our bugzilla categories
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? -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
Re: defining and revamping our bugzilla categories
On 10/11/07, James Hawkins <[EMAIL PROTECTED]> 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. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: defining and revamping our bugzilla categories
On 10/11/07, Jesse Allen <[EMAIL PROTECTED]> wrote: > On 10/11/07, James Hawkins <[EMAIL PROTECTED]> wrote: > > On 10/11/07, Detlef Riekenberg <[EMAIL PROTECTED]> 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. -- James Hawkins
Re: defining and revamping our bugzilla categories
On 10/11/07, James Hawkins <[EMAIL PROTECTED]> wrote: > On 10/11/07, Detlef Riekenberg <[EMAIL PROTECTED]> 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"?
Re: defining and revamping our bugzilla categories
On 10/11/07, Detlef Riekenberg <[EMAIL PROTECTED]> 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
Re: defining and revamping our bugzilla categories
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" -- By by ... Detlef
Re: defining and revamping our bugzilla categories
On Wed, Oct 10, 2007 at 03:52:36PM -0500, James Hawkins wrote:
> On 10/10/07, Louis Lenders <[EMAIL PROTECTED]> 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
Re: defining and revamping our bugzilla categories
On 10/10/07, Louis Lenders <[EMAIL PROTECTED]> wrote:
> James Hawkins 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).
--
James Hawkins
Re: defining and revamping our bugzilla categories
James Hawkins 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.
Re: defining and revamping our bugzilla categories
On 10/10/07, Jan Zerebecki <[EMAIL PROTECTED]> 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
Re: defining and revamping our bugzilla categories
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.
defining and revamping our bugzilla categories
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.
