Hi all, just some quick questions.
Is it just me or has anyone else noticed that the documentation for wine is kind of scattered all over the place? I mean personally I can name about 8 different places (that are affiliated with winehq) that people can go to get information, not including the mailing lists. IMHO if it were even possible to consolidate all of the information, it would still take months to do, especially with people not knowing to post to the central location.
Also, is it against the rules in bugzilla to try to organize the bugs some way? IOW The very old games metabug that I created (bug 1434).. I originally opened it not realizing that if every bug related to a game was attached the page would become overloaded. So I decided a year or two ago to close it. Then I recently realized how I could reorganize it and decided to reopen it, only to have it closed again by someone else who in not so many words told me that I was spamming the bug list and that I was annoying everyone.
Basically my idea was to make several tasklists to link to 1434 (bugs like dinput9, d3d8, etc), and then link individual games to each of those, so that someone working on games, and in specific on dinput9 for example could easily find bugs related to dinput 9 without having to do a query. But now I am worried that I am overstepping my bounds by trying to do so. Does anyone _else_ object to this idea?
Tom Spear wrote:
Hi all, just some quick questions.
Also, is it against the rules in bugzilla to try to organize the bugs some way? IOW The very old games metabug that I created (bug 1434)..
Bad idea. Metabugs are hard to follow and hard to use. Especially if _every game in the whole wide world_ will make it into your metabug.
In turn _any_ change to _any_ of the bugs will create a huge number of e-mails sent. Sume people either subscribed to wine-bugs or watch ML archive.
by someone else who in not so many words told me that I was spamming the bug list and that I was annoying everyone.
I think you should have asked first on the list. There are number of people who watch over bugzilla. And any change on such a scale would be good to discuss here
Basically my idea was to make several tasklists to link to 1434 (bugs like dinput9, d3d8, etc), and then link individual games to each of those, so that someone working on games, and in specific on dinput9 for example could easily find bugs related to dinput 9 without having to do a query. But now I am worried that I am overstepping my bounds by trying to do so. Does anyone _else_ object to this idea?
I do. As I explained above - using generic metabugs is bad. We have components that do exactly that. Also we have keywords that cover things from the different perspective. Those two are enough to do what you want to do.
Honestly we could do a better job at creating bug dependencies instead of closing lots of bugs as duplicates. But that's about it.
Vitaliy.
On Mon, Mar 19, 2007 at 11:04:58AM -0500, Tom Spear wrote:
Is it just me or has anyone else noticed that the documentation for wine is kind of scattered all over the place? I mean personally I can name about 8 different places (that are affiliated with winehq) that people can go to get information, not including the mailing lists.
Yea it would be good to collect information on winehq.org and not scatter it all over the web. I think there are all the (web)tools on winehq.org one needs for that, or is anyone missing something? (Other than that the bugzilla could really use an upgrade.)
Basically my idea was to make several tasklists to link to 1434 (bugs like dinput9, d3d8, etc), and then link individual games to each of those, so that someone working on games, and in specific on dinput9 for example could easily find bugs related to dinput 9 without having to do a query. But now I am worried that I am overstepping my bounds by trying to do so. Does anyone _else_ object to this idea?
Bugzilla queries are just a URL and it remains valid. So there is not much advantage to having a bug, right? But using components and keywords (in newer bugzillas there are even more ways to classify bugs) has the advantage that a change only triggers one change-mail. If the current components are not fain grained enough, we can always add more (and change the current ones).
BTW. I think the current component descriptions need to be enhanced, we should at least assign each .dll to one component (would make it much more obvious what should go where).
Jan
On 3/20/07, Jan Zerebecki jan.wine@zerebecki.de wrote:
On Mon, Mar 19, 2007 at 11:04:58AM -0500, Tom Spear wrote:
Is it just me or has anyone else noticed that the documentation for wine is kind of scattered all over the place? I mean personally I can name about 8 different places (that are affiliated with winehq) that people can go to get information, not including the mailing lists.
Yea it would be good to collect information on winehq.org and not scatter it all over the web. I think there are all the (web)tools on winehq.org one needs for that, or is anyone missing something? (Other than that the bugzilla could really use an upgrade.)
Basically my idea was to make several tasklists to link to 1434 (bugs like dinput9, d3d8, etc), and then link individual games to each of those, so that someone working on games, and in specific on dinput9 for example could easily find bugs related to dinput 9 without having to do a query. But now I am worried that I am overstepping my bounds by trying to do so. Does anyone _else_ object to this idea?
Bugzilla queries are just a URL and it remains valid. So there is not much advantage to having a bug, right? But using components and keywords (in newer bugzillas there are even more ways to classify bugs) has the advantage that a change only triggers one change-mail. If the current components are not fain grained enough, we can always add more (and change the current ones).
BTW. I think the current component descriptions need to be enhanced, we should at least assign each .dll to one component (would make it much more obvious what should go where).
Jan
Thanks for all of your feedback, that helps me understand a lot better. I'm still used to the 'old' way of doing things (its been a while since I've been able to actively contribute) where we create a bug for it even if it isnt a bug, and then close ones we dont need anymore.. I'll make sure to check on the list in the future and my apologies for the spam to both this list and to the bug list for all of the "work" I was doing.
On 3/20/07, Jan Zerebecki jan.wine@zerebecki.de wrote:
Yea it would be good to collect information on winehq.org and not scatter it all over the web. I think there are all the (web)tools on winehq.org one needs for that, or is anyone missing something? (Other than that the bugzilla could really use an upgrade.)
Bugzilla queries are just a URL and it remains valid. So there is not much advantage to having a bug, right? But using components and keywords (in newer bugzillas there are even more ways to classify bugs) has the advantage that a change only triggers one change-mail. If the current components are not fain grained enough, we can always add more (and change the current ones).
BTW. I think the current component descriptions need to be enhanced, we should at least assign each .dll to one component (would make it much more obvious what should go where).
I tend to agree on both parts. Bugzilla does need an upgrade, but the problems are that we have no test server to make sure it will go without hiccups, at least not to my knowledge, and that with the last upgrade wiping out 3/4 of the tables of the bug comments, Jeremy is a bit wary of fixing something that isnt 100% broken, which I don't blame him for.
However, the components could use a major revamping and should be fairly trivial. However I think that one component for each dll might be a bit much.. Maybe narrow the dll's down to categories such as wine-common-controls, and wine-riched..
My 2 biggest problems honestly are with the components we do have and with the search page. If we could fix the components it would be _much_ easier.. AFAIK there isnt much that can be done to the search page on wine's end, all changes would have to go in at the mozilla bugzilla tree.
I'd be happy to help with other ideas for components, just let me know.
On 3/20/07, Tom Spear speeddymon@gmail.com wrote:
On 3/20/07, Jan Zerebecki jan.wine@zerebecki.de wrote:
Yea it would be good to collect information on winehq.org and not scatter it all over the web. I think there are all the (web)tools on winehq.org one needs for that, or is anyone missing something? (Other than that the bugzilla could really use an upgrade.)
Bugzilla queries are just a URL and it remains valid. So there is not much advantage to having a bug, right? But using components and keywords (in newer bugzillas there are even more ways to classify bugs) has the advantage that a change only triggers one change-mail. If the current components are not fain grained enough, we can always add more (and change the current ones).
BTW. I think the current component descriptions need to be enhanced, we should at least assign each .dll to one component (would make it much more obvious what should go where).
I tend to agree on both parts. Bugzilla does need an upgrade, but the problems are that we have no test server to make sure it will go without hiccups, at least not to my knowledge, and that with the last upgrade wiping out 3/4 of the tables of the bug comments, Jeremy is a bit wary of fixing something that isnt 100% broken, which I don't blame him for.
However, the components could use a major revamping and should be fairly trivial. However I think that one component for each dll might be a bit much.. Maybe narrow the dll's down to categories such as wine-common-controls, and wine-riched..
No, we had vague components before, and they're not useful. We need a component per dll. I don't think we should add them all right now, but when we have a bug report for a bug in a particular dll that isn't a component yet, the component should be added (by request).
My 2 biggest problems honestly are with the components we do have and with the search page. If we could fix the components it would be _much_ easier.. AFAIK there isnt much that can be done to the search page on wine's end, all changes would have to go in at the mozilla bugzilla tree.
What's wrong with the components (besides the possible lack of components for some dlls) and the search page?
On 3/20/07, James Hawkins truiken@gmail.com wrote:
On 3/20/07, Tom Spear speeddymon@gmail.com wrote:
What's wrong with the components (besides the possible lack of components for some dlls) and the search page?
Well just that some of them are not very clear, wine-binary for one. What would be an example of something that should go under that component? Some are nonexistent, keyboard/mouse problems outside of games/dinput that dont cause a crash and aren't related to NLS.. Perhaps a component for keyboard and mice input. Although now that I think about it, dinput is a bit general too, because it handles so much. dinput IMHO should be split into keyboard input, mouse input, and something else for joystick/gamepads/etc since there are different people that work on those 3 distinct parts of dinput.
As for the search page, when I first saw it (when I was a new user) I was inundated by it and had to thoroughly read each thing and try to comprehend it.. Because the default search box at the top only searches the summary.
We always say that users need to search bugzilla for their bug before filing one, but nobody wants to have to unselect all of the statuses (so that all bugs are searched), and then have to still go and setup an advanced query just to search all bugs in their entirety for the word winrar..
Example: I click Query bugs, and type winrar and hit search. I get 3 bugs. But if I unselect all of the statuses, then I get 9 bugs, and if I use the boolean charts at the bottom, and do summary contains any of the words winrar or comment contains any of the words winrar, then I get 23 bugs.
I just think that mozilla (since we cant/wont) should give 2 search pages with google-like functionality, 1 search box, you type what you want to find, and hit search and it searches all of the bugs in their entirety. Then if you need a more advanced search then they show everything on the current search page except for the boolean charts, and if you need a fine-grained search then you can click a link to get to the boolean charts..
On a side note, I just realized that there is a way to search the comments without having to use the boolean charts, but that still doesnt solve the problem of having to unselect all of the statuses so that I can search all bugs..
On Tue, Mar 20, 2007 at 01:32:30PM -0500, Tom Spear wrote:
On 3/20/07, James Hawkins truiken@gmail.com wrote: I just think that mozilla (since we cant/wont) should give 2 search pages with google-like functionality, 1 search box, you type what you want to find, and hit search and it searches all of the bugs in their entirety. Then if you need a more advanced search then they show everything on the current search page except for the boolean charts, and if you need a fine-grained search then you can click a link to get to the boolean charts..
On a side note, I just realized that there is a way to search the comments without having to use the boolean charts, but that still doesnt solve the problem of having to unselect all of the statuses so that I can search all bugs..
All it takes to make such a page would be some HTML with a form that submits the correct querry to the search.
Jan
On 3/20/07, Tom Spear speeddymon@gmail.com wrote:
On 3/20/07, James Hawkins truiken@gmail.com wrote:
On 3/20/07, Tom Spear speeddymon@gmail.com wrote:
What's wrong with the components (besides the possible lack of components for some dlls) and the search page?
Well just that some of them are not very clear, wine-binary for one. What would be an example of something that should go under that component? Some are nonexistent, keyboard/mouse problems outside of games/dinput that dont cause a crash and aren't related to NLS.. Perhaps a component for keyboard and mice input. Although now that I think about it, dinput is a bit general too, because it handles so much. dinput IMHO should be split into keyboard input, mouse input, and something else for joystick/gamepads/etc since there are different people that work on those 3 distinct parts of dinput.
As for the search page, when I first saw it (when I was a new user) I was inundated by it and had to thoroughly read each thing and try to comprehend it.. Because the default search box at the top only searches the summary.
We always say that users need to search bugzilla for their bug before filing one, but nobody wants to have to unselect all of the statuses (so that all bugs are searched), and then have to still go and setup an advanced query just to search all bugs in their entirety for the word winrar..
You shouldn't be searching all bugs when filing a new bug...the reason to search for bugs (in the case of a new bug report) is to make sure you're not making a duplicate report. A new bug can't be a duplicate of a closed bug (technically not always true, but for all intents and purposes, the generalization can be made).
Example: I click Query bugs, and type winrar and hit search. I get 3 bugs. But if I unselect all of the statuses, then I get 9 bugs, and if I use the boolean charts at the bottom, and do summary contains any of the words winrar or comment contains any of the words winrar, then I get 23 bugs.
I just think that mozilla (since we cant/wont) should give 2 search pages with google-like functionality, 1 search box, you type what you want to find, and hit search and it searches all of the bugs in their entirety. Then if you need a more advanced search then they show everything on the current search page except for the boolean charts, and if you need a fine-grained search then you can click a link to get to the boolean charts..
On a side note, I just realized that there is a way to search the comments without having to use the boolean charts, but that still doesnt solve the problem of having to unselect all of the statuses so that I can search all bugs..
On 3/20/07, James Hawkins truiken@gmail.com wrote:
On 3/20/07, Tom Spear speeddymon@gmail.com wrote: You shouldn't be searching all bugs when filing a new bug...the reason to search for bugs (in the case of a new bug report) is to make sure you're not making a duplicate report. A new bug can't be a duplicate of a closed bug (technically not always true, but for all intents and purposes, the generalization can be made).
Thats just the problem. Not all users are using the latest and greatest wine and those that aren't usually dont realize they aren't. So if we resolve or close a bug because it's fixed in the latest snapshot, if we dont search all bugs, then the user doesnt find it and we end up with duplicates.
While technically you are right a user could be using the latest snapshot and have a closed bug come up too, if they have done enough research to search for their bug first, then they will probably be able to tell by the comments in a closed bug that that particular bug applied to an older version and therefore the symptoms need to be documented and so they need to file a new bug.
It is kind of a catch 22 because if we leave it as is, then we get dupes, but if we change it then a new bug that is like an old one but caused by different symptoms may not get reported right away.
Perhaps a new option under user preferences for beginner search (where it doesnt search all bugs) and non-beginner search (where it does), and then still have the different search pages too would be nice. Could either of the above changes conceivably be made in our local bugzilla easily?
Tom Spear wrote:
On 3/20/07, James Hawkins truiken@gmail.com wrote:
On 3/20/07, Tom Spear speeddymon@gmail.com wrote:
What's wrong with the components (besides the possible lack of components for some dlls) and the search page?
Well just that some of them are not very clear, wine-binary for one. What would be an example of something that should go under that component? Some are nonexistent, keyboard/mouse problems outside of games/dinput that dont cause a crash and aren't related to NLS.. Perhaps a component for keyboard and mice input. Although now that I think about it, dinput is a bit general too, because it handles so much. dinput IMHO should be split into keyboard input, mouse input, and something else for joystick/gamepads/etc since there are different people that work on those 3 distinct parts of dinput.
Actually no. All those 3 parts are closer together then you think. And if you search for dinput bugs you will get a whopping 16 open bugs. What should be expanded is x11drv. It has 157 open bugs which could be categorized better then that.
IMHO don't create any extra components until we really have a need for it. As an example see rebar component which was created for Dan's effort to get that part of the common controls fixed. However all bugs where reclassified as wine-commtl32.
Vitaliy.
James Hawkins <truiken <at> gmail.com> writes:
However, the components could use a major revamping and should be fairly trivial. However I think that one component for each dll might be a bit much.. Maybe narrow the dll's down to categories such as wine-common-controls, and wine-riched..
No, we had vague components before, and they're not useful.
Yeah, i use bugzilla for quite some time and from some components i still have no idea what they mean, and some are never used at all:
*wine-console (i could guess, but i've never seen a bug with this component) *directx and directx-d3d. (ok , directx is more than d3d, but we already have components for dinput, dmusic etc. so why not remove directx) *wine-files (no idea what it means, no files ever seen with this component) *wine-gui (what does that mean?) *wine-ipc(never seen a bug with that component) *wine-multimedia (just change to winmm i'd say) *wine-ports (?) *wine-Rebar( could be moved to comctl32?) *wine- resources( (never seen a bug with that component) *wine-winelib ( (never seen a bug with that component))
My opininion is : please remove /change
We need a component per dll.
Yeah, common dlls not yet added that come in my mind are urlmon, mshtml, shlwapi and advapi32.
I don't think we should add them all right now, but when we have a bug report for a bug in a particular dll that isn't a component yet, the component should be added (by request).
On 3/20/07, Louis Lenders xerox_xerox2000@yahoo.co.uk wrote:
James Hawkins <truiken <at> gmail.com> writes:
However, the components could use a major revamping and should be fairly trivial. However I think that one component for each dll might be a bit much.. Maybe narrow the dll's down to categories such as wine-common-controls, and wine-riched..
No, we had vague components before, and they're not useful.
Yeah, i use bugzilla for quite some time and from some components i still have no idea what they mean, and some are never used at all:
*wine-console (i could guess, but i've never seen a bug with this component) *directx and directx-d3d. (ok , directx is more than d3d, but we already have components for dinput, dmusic etc. so why not remove directx) *wine-files (no idea what it means, no files ever seen with this component)
*wine-gui (what does that mean?)
We made a big push a while back to correctly relabel wine-gui to their correct components (comctl32, gdi, etc).
*wine-ipc(never seen a bug with that component) *wine-multimedia (just change to winmm i'd say) *wine-ports (?) *wine-Rebar( could be moved to comctl32?) *wine- resources( (never seen a bug with that component) *wine-winelib ( (never seen a bug with that component))
My opininion is : please remove /change
The only component in that list that needs to go or change is wine-gui. Just because we don't have bug reports currently for all components doesn't mean that we wont get reports for them or that they're not necessary.
We need a component per dll.
Yeah, common dlls not yet added that come in my mind are urlmon, mshtml, shlwapi and advapi32.
I don't think we should add them all right now, but when we have a bug report for a bug in a particular dll that isn't a component yet, the component should be added (by request).
-
James Hawkins -
Jan Zerebecki -
Louis Lenders -
Tom Spear -
Vitaliy Margolen