Re: New metabugs

[Dan Kegel]

Hatky wrote:
> Ok so mybe the fix-me/stub/unimplemented bugs category
> is a really bad idea but we are having diffrent
> opinions on the more general idea of using metabugs as
> categories...

Hi Hatky,
I appreciate the energy you're bringing to the wine project!

That said, it might be a good idea for you to tread lightly
at least at first in the winehq bugzilla.  Like you, I just
started contributing to a bugzilla (OpenOffice's), and
the guys there are probably as nervous about me messing
with their bugzilla as I am about you messing around in
Wine's bugzilla!  So I'm being cautious, and instead of
creating a metabug right off the bat, I created some canned
queries and links to bugs on my own web site
  (http://www.kegel.com/openoffice/)
to try out my ideas first.  And when the openoffice qa mailing
list folks say "yeah, go ahead and create a metabug", I will -
but one at a time, and gently.

Anyway, don't let me slow you down.  Just remember that
bug tracking is a social issue, and you have to pay attention
to how the other developers feel about it.

Cheers,
Dan

New metabugs

[hatky]

--- Dan Kegel  wrote:
> Hatky wrote:
> > Ok so mybe the fix-me/stub/unimplemented bugs
>
> category
> > is a really bad idea but we are having diffrent
> > opinions on the more general idea of using
>
> metabugs as
> > categories...
>
> Hi Hatky,
> I appreciate the energy you're bringing to the wine
> project!

Thanks a lot.
> That said, it might be a good idea for you to tread
> lightly
> at least at first in the winehq bugzilla.

Tread lightly? you mean little changes insted of the
full reorginaztion I was trying to make?
> Like you,
> I just
> started contributing to a bugzilla (OpenOffice's),
> and
> the guys there are probably as nervous about me
> messing
> with their bugzilla as I am about you messing around
> in
> Wine's bugzilla!  So I'm being cautious, and instead
> of
> creating a metabug right off the bat, I created some
> canned
> queries and links to bugs on my own web site
>   (http://www.kegel.com/openoffice/)
> to try out my ideas first.  And when the openoffice
> qa mailing
> list folks say "yeah, go ahead and create a
> metabug", I will -
> but one at a time, and gently.
>
> Anyway, don't let me slow you down.  Just remember
> that
> bug tracking is a social issue, and you have to pay
> attention
> to how the other developers feel about it.

I am not sure what they realy think yes I only got 3
responces 2 of witch where positive :)...
I guess I will have to wait for the next week to start
when codewaver will return to flame me (or not) :)

I was also helping close a few bugs and I am sure that
is not bad :).
> Cheers,
> Dan
>
> -- 
> Dan Kegel
> http://www.kegel.com

http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
>

Thank for your toughts,
Hatky.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

New metabugs

[Francois Gouget]

On Fri, 2 May 2003, hatky wrote:
[...]
> > Anyway, don't let me slow you down.  Just remember that
> > bug tracking is a social issue, and you have to pay attention
> > to how the other developers feel about it.
>
> I am not sure what they realy think yes I only got 3
> responces 2 of witch where positive :)...
> I guess I will have to wait for the next week to start
> when codewaver will return to flame me (or not) :)

This is Wine's bugzilla so you don't need to worry about CodeWeavers
flaming you (or about the CodeWeavers' needs). However, as Dan said,
beware of the Wine developpers ;-).

I know I used meta-bugs in the past and we used them too in our internal
CodeWeavers bugzilla database. But meta-bugs are not very practical in
the long term and it is worth considering alternatives. In particular:

* Component field
   Some developpers are specialized in a certain aspect of Wine. Havnig
specialists is good, it's certainly more efficient than having to learn
from scratch each time. So we need to provide a way for specialists to
find bugs in their area of expertise.
   The 'Component' field is one way to do so. Let's say you're a
Direct3D specialist, you can find bugs in that area by querying Bugzilla
for all bugs tagged with 'Component=wine-directx'.

* keywords
   Keywords are another way to tag and query bugs. It's pretty flexible
and even lets you put multiple keywords on a bug. For instance you can
find all the bugs related to conformance testing by querying Bugzilla
for bugs that have the 'conformance' keyword. Similarly you can look for
all bugs related to programs for which the source is available by
searching for bugs with the 'source' keyword.
   See http://bugs.winehq.com/describekeywords.cgi

That being said,

* Bugzilla queries don't appear to work. Newman do you know what's up?
Is it a database performance issue? Bugzilla bug?

* Direct3D and DirectSound are pertty different areas. Maybe we should
split the wine-directx component into direct3d, directdraw, directsound
and the generic directx.

* Maybe we need a 'wine-msvcrt' component. I know there are people
interested in msvcrt but looking at the component list I don't know
where such bugs would go. Or maybe we should be a bit more general and
have a 'wine-libc' so that it includes crtdll and potential future C++
libraries, etc.

* Maybe we should add more keywords. I'm not saying we should do it,
but adding 'game' keyword would provide the same functionality as the
current game meta-bug. If we go this way, I could see another useful
keyword: 'installer' to identify all bugs related to application
installers. But we have to be careful not to add frivolous keywords.

* One useful things that can be done now is to inspect all new bugs to
make sure that:
   - the component field is set correctly
   - the download URL to the binary or source is provided if applicable
     (in case of doubt ask the reporter)
   - all applicable keywords are set
   That said, things seem to be already pretty much in order (more so
for the component field than for keywords).

* Maybe people don't know about the keywords, components and Bugzilla
queries. Maybe they need to be publicized somewhat.

New metabugs

[hatky]

Thanks Francois,
Your response was the most educating for me...
--- Francois Gouget  wrote:
> On Fri, 2 May 2003, hatky wrote:
> [...]
> > > Anyway, don't let me slow you down.  Just
>
> remember that
> > > bug tracking is a social issue, and you have to
>
> pay attention
> > > to how the other developers feel about it.
> >
> > I am not sure what they realy think yes I only got
>
> 3
> > responces 2 of witch where positive :)...
> > I guess I will have to wait for the next week to
>
> start
> > when codewaver will return to flame me (or not) :)
>
> This is Wine's bugzilla so you don't need to worry
> about CodeWeavers
> flaming you (or about the CodeWeavers' needs).
> However, as Dan said,
> beware of the Wine developpers ;-).

I do not fear my own breed.
> I know I used meta-bugs in the past and we used them
> too in our internal
> CodeWeavers bugzilla database. But meta-bugs are not
> very practical in
> the long term and it is worth considering
> alternatives. In particular:
> - Component field
> Some developpers are specialized in a certain
>
> aspect of Wine. Havnig
> specialists is good, it's certainly more efficient
> than having to learn
> from scratch each time. So we need to provide a way
> for specialists to
> find bugs in their area of expertise.
>    The 'Component' field is one way to do so. Let's
> say you're a
> Direct3D specialist, you can find bugs in that area
> by querying Bugzilla
> for all bugs tagged with 'Component=wine-directx'.
> - keywords
> Keywords are another way to tag and query bugs.
>
> It's pretty flexible
> and even lets you put multiple keywords on a bug.
> For instance you can
> find all the bugs related to conformance testing by
> querying Bugzilla
> for bugs that have the 'conformance' keyword.
> Similarly you can look for
> all bugs related to programs for which the source is
> available by
> searching for bugs with the 'source' keyword.
>    See http://bugs.winehq.com/describekeywords.cgi

This is very intersting and I actually did not really
know about keywords I seen them some where but I never
seen this link and it does look like a good way for
doing this kind of stuff, I just now know I can
actully update this....
> That being said,
> - Bugzilla queries don't appear to work. Newman do
>
> you know what's up?
> Is it a database performance issue? Bugzilla bug?

I had this problem but I tought the bug was me since
some simple querys did work and I have never used the
search,,,
> - Direct3D and DirectSound are pertty different
>
> areas. Maybe we should
> split the wine-directx component into direct3d,
> directdraw, directsound
> and the generic directx.

That would be a nice idea.
> - Maybe we need a 'wine-msvcrt' component. I know
>
> there are people
> interested in msvcrt but looking at the component
> list I don't know
> where such bugs would go. Or maybe we should be a
> bit more general and
> have a 'wine-libc' so that it includes crtdll and
> potential future C++
> libraries, etc.

No comment.
> - Maybe we should add more keywords. I'm not saying
>
> we should do it,
> but adding 'game' keyword would provide the same
> functionality as the
> current game meta-bug. If we go this way, I could
> see another useful
> keyword: 'installer' to identify all bugs related to
> application
> installers. But we have to be careful not to add
> frivolous keywords.

I am highly for doing this and for both the 'game' and
'installer' keywords and I can not actually think of
more to add and thats rare in my case :).
> - One useful things that can be done now is to
>
> inspect all new bugs to
> make sure that:
> - the component field is set correctly
> - the download URL to the binary or source is
>
> provided if applicable
>      (in case of doubt ask the reporter)
> - all applicable keywords are set
>
> That said, things seem to be already pretty much
> in order (more so
> for the component field than for keywords).

I know mine sould be redone where keywords is
concerned I will do it soon.
> - Maybe people don't know about the keywords,
>
> components and Bugzilla
> queries. Maybe they need to be publicized somewhat.

A simple link somewhere would do it justice (a block
would make it even cool).
> -- 
> Francois Gouget         [e-mail]       
> http://fgouget.free.fr/
>                   A black hole is just God dividing
> by zero.

Thanks a LOT Francois,
Hatky.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

New metabugs

[Shachar Shemesh]

Francois Gouget wrote:
> On Fri, 2 May 2003, hatky wrote:
> [...]
> > > Anyway, don't let me slow you down.  Just remember that
> > > bug tracking is a social issue, and you have to pay attention
> > > to how the other developers feel about it.
> >
> > I am not sure what they realy think yes I only got 3
> > responces 2 of witch where positive :)...
> > I guess I will have to wait for the next week to start
> > when codewaver will return to flame me (or not) :)
>
> This is Wine's bugzilla so you don't need to worry about CodeWeavers
> flaming you (or about the CodeWeavers' needs). However, as Dan said,
> beware of the Wine developpers ;-).
>
> I know I used meta-bugs in the past and we used them too in our internal
> CodeWeavers bugzilla database. But meta-bugs are not very practical in
> the long term and it is worth considering alternatives. In particular:
> - Component field
> Some developpers are specialized in a certain aspect of Wine. Havnig
>
> specialists is good, it's certainly more efficient than having to learn
> from scratch each time. So we need to provide a way for specialists to
> find bugs in their area of expertise.
>   The 'Component' field is one way to do so. Let's say you're a
> Direct3D specialist, you can find bugs in that area by querying Bugzilla
> for all bugs tagged with 'Component=wine-directx'.
> - keywords
> Keywords are another way to tag and query bugs. It's pretty flexible
>
> and even lets you put multiple keywords on a bug. For instance you can
> find all the bugs related to conformance testing by querying Bugzilla
> for bugs that have the 'conformance' keyword. Similarly you can look for
> all bugs related to programs for which the source is available by
> searching for bugs with the 'source' keyword.
>   See http://bugs.winehq.com/describekeywords.cgi
>
> That being said,
> - Bugzilla queries don't appear to work. Newman do you know what's up?
>
> Is it a database performance issue? Bugzilla bug?
> - Direct3D and DirectSound are pertty different areas. Maybe we should
>
> split the wine-directx component into direct3d, directdraw, directsound
> and the generic directx.
> - Maybe we need a 'wine-msvcrt' component. I know there are people
>
> interested in msvcrt but looking at the component list I don't know
> where such bugs would go. Or maybe we should be a bit more general and
> have a 'wine-libc' so that it includes crtdll and potential future C++
> libraries, etc.
> - Maybe we should add more keywords. I'm not saying we should do it,
>
> but adding 'game' keyword would provide the same functionality as the
> current game meta-bug. If we go this way, I could see another useful
> keyword: 'installer' to identify all bugs related to application
> installers. But we have to be careful not to add frivolous keywords.
> - One useful things that can be done now is to inspect all new bugs to
>
> make sure that:
> - the component field is set correctly
> - the download URL to the binary or source is provided if applicable
> (in case of doubt ask the reporter)
> - all applicable keywords are set
>
> That said, things seem to be already pretty much in order (more so
> for the component field than for keywords).

While wer'e at it, can we add a "BiDi" keyword, or at least a 
"complex-lang" keyword?

Shachar

New metabugs

[hatky]

Well I haven't seen any real answers about this,
Can anybody here add keywords to bugzilla?
Are you aggreing with the ones that are requested
here?

Anybody?

Hatky.
--- Shachar Shemesh  wrote:
> Francois Gouget wrote:
> > On Fri, 2 May 2003, hatky wrote:
> > [...]
> > > > Anyway, don't let me slow you down.  Just
>
> remember that
> > > > bug tracking is a social issue, and you have to
>
> pay attention
> > > > to how the other developers feel about it.
> > >
> > > I am not sure what they realy think yes I only got
>
> 3
> > > responces 2 of witch where positive :)...
> > > I guess I will have to wait for the next week to
>
> start
> > > when codewaver will return to flame me (or not) :)
> >
> > This is Wine's bugzilla so you don't need to worry
>
> about CodeWeavers
> > flaming you (or about the CodeWeavers' needs).
>
> However, as Dan said,
> > beware of the Wine developpers ;-).
> >
> > I know I used meta-bugs in the past and we used
>
> them too in our internal
> > CodeWeavers bugzilla database. But meta-bugs are
>
> not very practical in
> > the long term and it is worth considering
>
> alternatives. In particular:
> > - Component field
> > Some developpers are specialized in a certain
>
> aspect of Wine. Havnig
> > specialists is good, it's certainly more efficient
>
> than having to learn
> > from scratch each time. So we need to provide a way
>
> for specialists to
> > find bugs in their area of expertise.
> >   The 'Component' field is one way to do so. Let's
>
> say you're a
> > Direct3D specialist, you can find bugs in that area
>
> by querying Bugzilla
> > for all bugs tagged with 'Component=wine-directx'.
> > - keywords
> > Keywords are another way to tag and query bugs.
>
> It's pretty flexible
> > and even lets you put multiple keywords on a bug.
>
> For instance you can
> > find all the bugs related to conformance testing by
>
> querying Bugzilla
> > for bugs that have the 'conformance' keyword.
>
> Similarly you can look for
> > all bugs related to programs for which the source
>
> is available by
> > searching for bugs with the 'source' keyword.
> >   See http://bugs.winehq.com/describekeywords.cgi
> >
> > That being said,
> > - Bugzilla queries don't appear to work. Newman do
>
> you know what's up?
> > Is it a database performance issue? Bugzilla bug?
> > - Direct3D and DirectSound are pertty different
>
> areas. Maybe we should
> > split the wine-directx component into direct3d,
>
> directdraw, directsound
> > and the generic directx.
> > - Maybe we need a 'wine-msvcrt' component. I know
>
> there are people
> > interested in msvcrt but looking at the component
>
> list I don't know
> > where such bugs would go. Or maybe we should be a
>
> bit more general and
> > have a 'wine-libc' so that it includes crtdll and
>
> potential future C++
> > libraries, etc.
> > - Maybe we should add more keywords. I'm not
>
> saying we should do it,
> > but adding 'game' keyword would provide the same
>
> functionality as the
> > current game meta-bug. If we go this way, I could
>
> see another useful
> > keyword: 'installer' to identify all bugs related
>
> to application
> > installers. But we have to be careful not to add
>
> frivolous keywords.
> > - One useful things that can be done now is to
>
> inspect all new bugs to
> > make sure that:
> > - the component field is set correctly
> > - the download URL to the binary or source is
>
> provided if applicable
> > (in case of doubt ask the reporter)
> > - all applicable keywords are set
> >
> > That said, things seem to be already pretty much
>
> in order (more so
> > for the component field than for keywords).
>
> While wer'e at it, can we add a "BiDi" keyword, or
> at least a 
> "complex-lang" keyword?
>       Shachar
>
> -- 
> Shachar Shemesh
> Open Source integration consultant
> Home page & resume - http://www.shemesh.biz/

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

New metabugs

[Francois Gouget]

On Sun, 4 May 2003, hatky wrote:
> Well I haven't seen any real answers about this,
> Can anybody here add keywords to bugzilla?
> Are you aggreing with the ones that are requested
> here?

That's the thing with keywords an components, not everyone can create
them (which is a good thing). I'm not sure who has the right permissions
to create them (I don't).

* We *need* a way to find all 'open' bugs
   - concerning a given component
   - with a given keyword
   This doesn't work right now and it has to be fixed, even if it means
making special search form that only allows this kind of query because
the other types of queries take too much CPU.

* I propose adding the following components:
   wine-direct3d
   wine-directsound
   wine-directdraw
   wine-crt

* I'm ok with the 'game' and 'installer' keywords (singular, both).
   Though I am not 100% sure they are needed.
   (is it hard to remove a keyword?)

* I am not convinced we should have a 'bidi' keyword. A component may
be more approriate. Would the 'wine-gdi' component be suitable or is it
too crowded? Or maybe an 'internationalization' keyword (or 'i18n',
it's much shorter).

Another interesting thing is the 'Named Queries'. If you go to 'Find a
bug', you have the option to save the query and it will then appear in
your sidebar in the 'Named Queries' section. So if you're a DirectX
developper you could have a 'DirectX bugs' query that returns all the
open bugs for the 'wine-directx' component.

New metabugs

[Francois Gouget]

I continued looking at the component list and especially the component
definition page:
http://bugs.winehq.com/describecomponents.cgi?product=Wine

Some interesting things I noticed:

* wine-patches
   'Report consisting solely of a patch'

I think this should be a keyword, 'patch', rather than a component.

* wine-help
   'Basic support or configuration request'

I think such requests belong to wine-users rather than Bugzilla. The
reason is that I see Bugzilla as a way for developpers to track bugs in
the code and reports such as 'Application foo does not work' are
quite useless to developpers. They start to become more useful when you
get to the level of a crash with a relay log, a stack trace, a
meaningful FIXME, etc.
   That being said, I'm not sure it would be 'right' to close such bugs.
But I think our policy should be to at least direct the reporter to
wine-users and assign the bug to the 'wine-help' component.

* wine-ole
   'OLE, Active X'

We should change the description as follows:
   'OLE, Active X, Com, DCOM'

* wine-directx
   'DirectDraw, DirectSound, Direct3D, DirectPlay'

I noticed some DirectSound bugs were assigned to 'wine-multimedia'
and it's true that there can be some confusion. The above settles it.

* wine-gdi
   'Drawing, graphics, fonts, drivers'

That appears to include BiDi. But I still think an
internationalization keyword that would cover BiDi, XIM, dead-keys, and
localization of resources would be a good thing.

* wine-gui
   'Controls, dialogs, shell'

I was wondering where 'shell' bugs should go. 'wine-gui' it is
apparently.

* Nothing says where registry issues should go. 'wine-kernel'?
   Same question for opengl issues.
   For msvcrt/crtdll issues (but I already proposed to add wine-crt). We
really need it too, I have seen at least a dozen msvcrt bugs assigned to
various components, the most common one being 'wine-misc'!

* I still think it would be nice to be able to attach a bug to a
specific dll. I don't know if that means we should add a bunch of
components or a bunch of keywords or find yet another mechanism.
   Similarly having keywords/components corresponding to the debug
channels would be nice.

New metabugs

[Dimitrie O. Paun]

On May 4, 2003 10:27 pm, Francois Gouget wrote:
> I continued looking at the component list and especially the component
> definition page:
> http://bugs.winehq.com/describecomponents.cgi?product=Wine
>
> Some interesting things I noticed:
> -
>
> wine-patches
> 'Report consisting solely of a patch'
>
> I think this should be a keyword, 'patch', rather than a component.

It should die, for sure. Patches should be sent to wine-{patches,devel}
for inclusion or discussion. I have patches submitted to Bugzilla, they
have about 0 visibility. A much better way to do it is to submit the
patch to one of the above mentioned lists, and add a link to the archived
message. This way:
  -- You get the patch out there, to a much wider audience
  -- You can have discution threads about it via regular email
  -- You get to link it to the bug, if relevant.
> -
>
> wine-help
> 'Basic support or configuration request'
>
> I think such requests belong to wine-users rather than Bugzilla. The
>
> reason is that I see Bugzilla as a way for developpers to track bugs in
> the code and reports such as 'Application foo does not work' are
> quite useless to developpers. They start to become more useful when you
> get to the level of a crash with a relay log, a stack trace, a
> meaningful FIXME, etc.
>    That being said, I'm not sure it would be 'right' to close such bugs.
> But I think our policy should be to at least direct the reporter to
> wine-users and assign the bug to the 'wine-help' component.

Agreed. Let's nuke it.
> - I still think it would be nice to be able to attach a bug to a
>
> specific dll. I don't know if that means we should add a bunch of
> components or a bunch of keywords or find yet another mechanism.
>    Similarly having keywords/components corresponding to the debug
> channels would be nice.

Maybe nice, but most likely overkill. Bugzilla is way too complicated
already, half of it's features are most likely never used. You need a
degree in Bugzilla to operate it properly, this would just make it
even more complicated...

New metabugs

[Francois Gouget]

On Mon, 5 May 2003, Dimitrie O. Paun wrote:
> On May 4, 2003 10:27 pm, Francois Gouget wrote:

[...]
> > -
> >
> > wine-patches
> > 'Report consisting solely of a patch'
> >
> > I think this should be a keyword, 'patch', rather than a component.
>
> It should die, for sure. Patches should be sent to wine-{patches,devel}
> for inclusion or discussion. I have patches submitted to Bugzilla, they
> have about 0 visibility. A much better way to do it is to submit the
> patch to one of the above mentioned lists, and add a link to the archived
> message. This way:
>   -- You get the patch out there, to a much wider audience
>   -- You can have discution threads about it via regular email
>   -- You get to link it to the bug, if relevant.

Some patches will inevitably end up in bugzilla. So we'll need people to
submit them to wine-devel/wine-patches but tagging the relevant bugs
would really help tracking them.
> > - wine-help
> > 'Basic support or configuration request'

[...]
> Agreed. Let's nuke it.

Do you want to nuke the bugs or the wine-help component? If the former
then it's ok to nuke that component but otherwise we'll need it.
> > - I still think it would be nice to be able to attach a bug to a
> >
> > specific dll. I don't know if that means we should add a bunch of
> > components or a bunch of keywords or find yet another mechanism.
> >    Similarly having keywords/components corresponding to the debug
> > channels would be nice.
>
> Maybe nice, but most likely overkill. Bugzilla is way too complicated
> already, half of it's features are most likely never used. You need a
> degree in Bugzilla to operate it properly, this would just make it
> even more complicated...

Well often I know a bug is in shell32, but what component should that go
into? *That* requires a degree.

The problem is that our components don't have a one to one mapping with
dlls and that in many cases it's hard to know where to attach a bug.
This results in lots of bugs getting into the wrong category such as
wine-binary, wine-programs or wine-misc, which then makes it harder for
developpers to find bugs relevant to their area of expertise.

New metabugs

[Dimitrie O. Paun]

On May 5, 2003 07:01 pm, Francois Gouget wrote:
> Some patches will inevitably end up in bugzilla. So we'll need people to
> submit them to wine-devel/wine-patches but tagging the relevant bugs
> would really help tracking them.

Yeah, but if people don't know their way around Wine procedures, what are
the odds they'll tag the thing with 'patch'? If people who know these 
things notice such a patch in Bugzilla, it's WAY better that they suggest
the patch be submitted to wine-patches (or submit it themselves), rather
than creating a mechanism for perpetuating a practice we don't want.
> Do you want to nuke the bugs or the wine-help component? If the former
> then it's ok to nuke that component but otherwise we'll need it.

Both. They have no business in Bugzilla.
> Well often I know a bug is in shell32, but what component should that go
> into? *That* requires a degree.

Again, maybe, but there are *many* DLLs, and there isn't such a pressing
need to add all this complexity. Just put the name of the DLL in the
subject, and search for it there. That should do for now, no?

New metabugs

[hatky]

--- "Dimitrie O. Paun"  wrote:
> Again, maybe, but there are *many* DLLs, and there
> isn't such a pressing
> need to add all this complexity. Just put the name
> of the DLL in the
> subject, and search for it there. That should do for
> now, no?

I is posible and makes sence if we can not search by
component but don't forget the subject line has a
limit :)

Hatky.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

New metabugs

[hatky]

--- Francois Gouget  wrote:
> The problem is that our components don't have a one
> to one mapping with
> dlls and that in many cases it's hard to know where
> to attach a bug.
> This results in lots of bugs getting into the wrong
> category such as
> wine-binary, wine-programs or wine-misc, which then
> makes it harder for
> developpers to find bugs relevant to their area of
> expertise.

If it is so have seperating the components then I
think the components do not help us so why not reorder
them delete all the curent ones one components by dlls
I think it will be clearer to everyone...
or mybe just add by dll so unclear bugs will be
assigned to these general components

Just a tought,
Hatky.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

New metabugs

[Shachar Shemesh]

Francois Gouget wrote:
> -
>
> wine-gdi
> 'Drawing, graphics, fonts, drivers'
>
> That appears to include BiDi. But I still think an
>
> internationalization keyword that would cover BiDi, XIM, dead-keys, and
> localization of resources would be a good thing.

I am not sure what XIM is. In any case, I don't think BiDi+dead-keys 
should go in the same category as localization. The frist two are 
technological, and require a programmer knowledgable in the system, but 
which does not necessarily speak the language. The last is linguistic, 
and requires someone who speaks the language, but may not necesserilly 
know any programming at all.

As for components - some BiDi stuff goes in GDI - sure. Text rendering 
is one obvious example. Adding BiDi to the Edit Control should go in 
GUI, however. I'm not sure where bugs such as 1163 should go (currently 
filed under GUI, but should probably go to GDI, as the underscores are 
added by DrawText). 1158 is a definite GUI.

For those reasons I did not want to add a BiDi component, but rather a 
keyword.

New metabugs

[Shachar Shemesh]

Francois Gouget wrote:
> - I am not convinced we should have a 'bidi' keyword. A component may
>
> be more approriate. Would the 'wine-gdi' component be suitable or is it
> too crowded? Or maybe an 'internationalization' keyword (or 'i18n',
> it's much shorter).

Some BiDi bugs are in GDI, some in UI, some in common controls. I don't 
think specifying BiDi as a component is the right thing to do. It has no 
specific location in the sources, for one thing.

Right now BiDi bugs are blocking meta-bug 609 (opened by you, Francois 
:-). This actually makes sense, as the meta-bug has an owner (me), who 
is notified by email when something changes there (such as - the 
addition of bug 1425, which has now totally changed its name). As such, 
I'm not sure how important it is to have a keyword as well (though it 
will probably make it easier for people who are not familiar with 
meta-bug 609 to navigate the system).

New metabugs

[hatky]

I did not get your point about the querys if you click
on the "keywords" link you get to this page:
http://bugs.winehq.org/describekeywords.cgi
and it shows all keyword and when you click on them...
like source links to:
http://bugs.winehq.org/buglist.cgi?keywords=source
and it get you all the bugs with the keyword
source....
Was this what you were sujesting we need to do I am
asking becouse I really an not sure if I understod you
curectly

Sencirly,
Hatky.
-- Francois Gouget  wrote:
> On Sun, 4 May 2003, hatky wrote:
> > Well I haven't seen any real answers about this,
> > Can anybody here add keywords to bugzilla?
> > Are you aggreing with the ones that are requested
> > here?
>
> That's the thing with keywords an components, not
> everyone can create
> them (which is a good thing). I'm not sure who has
> the right permissions
> to create them (I don't).
> - We *need* a way to find all 'open' bugs
> - concerning a given component
> - with a given keyword
> This doesn't work right now and it has to be
>
> fixed, even if it means
> making special search form that only allows this
> kind of query because
> the other types of queries take too much CPU.
> -
>
> I propose adding the following components:
> wine-direct3d
> wine-directsound
> wine-directdraw
> wine-crt
> -
>
> I'm ok with the 'game' and 'installer' keywords
>
> (singular, both).
>    Though I am not 100% sure they are needed.
>    (is it hard to remove a keyword?)
> - I am not convinced we should have a 'bidi'
>
> keyword. A component may
> be more approriate. Would the 'wine-gdi' component
> be suitable or is it
> too crowded? Or maybe an 'internationalization'
> keyword (or 'i18n',
> it's much shorter).
>
> Another interesting thing is the 'Named Queries'. If
> you go to 'Find a
> bug', you have the option to save the query and it
> will then appear in
> your sidebar in the 'Named Queries' section. So if
> you're a DirectX
> developper you could have a 'DirectX bugs' query
> that returns all the
> open bugs for the 'wine-directx' component.
>
> -- 
> Francois Gouget         [e-mail]       
> http://fgouget.free.fr/
>         It really galls me that most of the computer
> power in the world
>                           is wasted on screen
> savers.
>                      Chris Caldwell from the GIMPS
> project
>
> http://www.mersenne.org/prime.htm

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

New metabugs

[Francois Gouget]

On Mon, 5 May 2003, hatky wrote:
> I did not get your point about the querys if you click
> on the "keywords" link you get to this page:
> http://bugs.winehq.org/describekeywords.cgi
> and it shows all keyword and when you click on them...
> like source links to:
> http://bugs.winehq.org/buglist.cgi?keywords=source
> and it get you all the bugs with the keyword
> source....

I was trying to get the bug list via 'Find a Bug' and that doesn't work.
It nice that we have this workaround for keywords. However I did not see
a similar workaround for components.

Plus saved queries and the 'My Bugs' and 'Bugs by Me' sidebar links
don't work anymore.

New metabugs

[hatky]

--- Francois Gouget  wrote:
> It nice that we have this workaround for keywords.
> However I did not see
> a similar workaround for components.

I am really suprised they do not have that, mybe in
the next version ;)
> Plus saved queries and the 'My Bugs' and 'Bugs by
> Me' sidebar links
> don't work anymore.

I have also noticed that.

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

New metabugs

[hatky]

So how does have rights to add these keywords? 
Mybe alexander is the only one?

Hatky.
--- Francois Gouget  wrote:
> On Sun, 4 May 2003, hatky wrote:
> > Well I haven't seen any real answers about this,
> > Can anybody here add keywords to bugzilla?
> > Are you aggreing with the ones that are requested
> > here?
>
> That's the thing with keywords an components, not
> everyone can create
> them (which is a good thing). I'm not sure who has
> the right permissions
> to create them (I don't).
> - We *need* a way to find all 'open' bugs
> - concerning a given component
> - with a given keyword
> This doesn't work right now and it has to be
>
> fixed, even if it means
> making special search form that only allows this
> kind of query because
> the other types of queries take too much CPU.
> -
>
> I propose adding the following components:
> wine-direct3d
> wine-directsound
> wine-directdraw
> wine-crt
> -
>
> I'm ok with the 'game' and 'installer' keywords
>
> (singular, both).
>    Though I am not 100% sure they are needed.
>    (is it hard to remove a keyword?)
> - I am not convinced we should have a 'bidi'
>
> keyword. A component may
> be more approriate. Would the 'wine-gdi' component
> be suitable or is it
> too crowded? Or maybe an 'internationalization'
> keyword (or 'i18n',
> it's much shorter).
>
> Another interesting thing is the 'Named Queries'. If
> you go to 'Find a
> bug', you have the option to save the query and it
> will then appear in
> your sidebar in the 'Named Queries' section. So if
> you're a DirectX
> developper you could have a 'DirectX bugs' query
> that returns all the
> open bugs for the 'wine-directx' component.
>
> -- 
> Francois Gouget         [e-mail]       
> http://fgouget.free.fr/
>         It really galls me that most of the computer
> power in the world
>                           is wasted on screen
> savers.
>                      Chris Caldwell from the GIMPS
> project
>
> http://www.mersenne.org/prime.htm

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com