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 -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
--- Dan Kegel <dank(a)kegel.com> 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
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. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.
Thanks Francois, Your response was the most educating for me... --- Francois Gouget <fgouget(a)free.fr> 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 fgouget(a)free.fr 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
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/
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 <wine-devel(a)shemesh.biz> 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
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 fgouget(a)free.fr 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
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. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner
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... -- Dimi.
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. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
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? -- Dimi.
--- "Dimitrie O. Paun" <dpaun(a)rogers.com> 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
--- Francois Gouget <fgouget(a)free.fr> 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
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. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
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). -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
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 <fgouget(a)free.fr> 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 fgouget(a)free.fr 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
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
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. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
--- Francois Gouget <fgouget(a)free.fr> 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
So how does have rights to add these keywords? Mybe alexander is the only one? Hatky. --- Francois Gouget <fgouget(a)free.fr> 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 fgouget(a)free.fr 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
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
participants (5)
-
Dan Kegel -
Dimitrie O. Paun -
Francois Gouget -
hatky -
Shachar Shemesh