"Sound" keyword on bugzilla
Hi, Joerg and I exchanged a couple of emails where I proposed a "sound" keyword on bugzilla. Reasoning: there are multiple sound components, and most of the time, the correct component is unknown (or could even be caused by non-sound components). Thoughts? J. Leclanche
Any comments? J. Leclanche On Tue, Jan 17, 2012 at 1:09 AM, Jerome Leclanche <adys.wh(a)gmail.com> wrote:
Hi,
Joerg and I exchanged a couple of emails where I proposed a "sound" keyword on bugzilla. Reasoning: there are multiple sound components, and most of the time, the correct component is unknown (or could even be caused by non-sound components).
Thoughts?
J. Leclanche
On Wed, Jan 18, 2012 at 07:03:24PM +0000, Jerome Leclanche wrote:
Any comments?
Seems like a useful idea to me, though I'd defer to the heavier Bugzilla users' opinions. Andrew
On Tue, Jan 17, 2012 at 1:09 AM, Jerome Leclanche <adys.wh(a)gmail.com> wrote:
Hi,
Joerg and I exchanged a couple of emails where I proposed a "sound" keyword on bugzilla. Reasoning: there are multiple sound components, and most of the time, the correct component is unknown (or could even be caused by non-sound components).
Thoughts?
J. Leclanche
On Wed, Jan 18, 2012 at 13:25, Andrew Eikum <aeikum(a)codeweavers.com> wrote:
On Wed, Jan 18, 2012 at 07:03:24PM +0000, Jerome Leclanche wrote:
Any comments?
Seems like a useful idea to me, though I'd defer to the heavier Bugzilla users' opinions.
Andrew
On Tue, Jan 17, 2012 at 1:09 AM, Jerome Leclanche <adys.wh(a)gmail.com> wrote:
Hi,
Joerg and I exchanged a couple of emails where I proposed a "sound" keyword on bugzilla. Reasoning: there are multiple sound components, and most of the time, the correct component is unknown (or could even be caused by non-sound components).
Thoughts?
I would say this is what components are for, though the point that pulseaudio/etc. bugs were filed as -unknown is valid. If no one opposes in the next few days I'll add it/start tagging bugs. -- -Austin
Austin English <austinenglish(a)gmail.com> wrote:
I would say this is what components are for, though the point that pulseaudio/etc. bugs were filed as -unknown is valid.
If no one opposes in the next few days I'll add it/start tagging bugs.
I'd oppose to adding yet another useless keyword just to avoid setting appropriate component. 'printing' is an example of another useless keyword. -- Dmitry.
I see your point on printing but I disagree on it being "useless". If "proper printing" had been a 1.4 milestone, I'm sure whoever would have worked on it would find it wonderfully useful. J. Leclanche On Fri, Jan 20, 2012 at 9:35 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Austin English <austinenglish(a)gmail.com> wrote:
I would say this is what components are for, though the point that pulseaudio/etc. bugs were filed as -unknown is valid.
If no one opposes in the next few days I'll add it/start tagging bugs.
I'd oppose to adding yet another useless keyword just to avoid setting appropriate component. 'printing' is an example of another useless keyword.
-- Dmitry.
Jerome Leclanche <adys.wh(a)gmail.com> wrote:
I see your point on printing but I disagree on it being "useless". If "proper printing" had been a 1.4 milestone, I'm sure whoever would have worked on it would find it wonderfully useful.
If somebody is lazy or clueless to set a proper bugzilla component, then using the word 'printing' somewhere in the bug summary would do the trick. -- Dmitry.
Hi, Austin English wrote:
If no one opposes in the next few days I'll add it/start tagging bugs. I'm no more opposed to adding a pseudo-component. I simply suggest naming it unknown-audio or unknown-sound instead of "sound" such that people will hopefully still use the existing quartz, mmdevapi, winealsa, winmm&mci, direct-dmusic and direct-dsound.
Dmitry Timoshkov wrote:
If somebody is lazy or clueless to set a proper bugzilla component, then using the word 'printing' somewhere in the bug summary would do the trick. Yes. I've sometimes appended "(MacOS/MP3/XYZ)" to summary lines so as to identify the area in search result listings.
Enhancement request: In search result listings, show the component instead of the assignee who is almost always wine-bugs(a)winehq -- useless waste of space. BTW, can I rename one of my saved searches? Thank you, Jörg Höhle
Joerg-Cyril.Hoehle(a)t-systems.com wrote:
Austin English wrote:
If no one opposes in the next few days I'll add it/start tagging bugs. I'm no more opposed to adding a pseudo-component. I simply suggest naming it unknown-audio or unknown-sound instead of "sound" such that people will hopefully still use the existing quartz, mmdevapi, winealsa, winmm&mci, direct-dmusic and direct-dsound.
How is that better than simple 'unknown'? P.S. Could you please fix your mailer to not strip "Re:" from subjects when replying? -- Dmitry.
On Fri, Jan 20, 2012 at 07:23:42PM +0800, Dmitry Timoshkov wrote:
Joerg-Cyril.Hoehle(a)t-systems.com wrote:
Austin English wrote:
If no one opposes in the next few days I'll add it/start tagging bugs. I'm no more opposed to adding a pseudo-component. I simply suggest naming it unknown-audio or unknown-sound instead of "sound" such that people will hopefully still use the existing quartz, mmdevapi, winealsa, winmm&mci, direct-dmusic and direct-dsound.
How is that better than simple 'unknown'?
Because then I can search for audio-related bugs where the component is not yet known.
Andrew Eikum <aeikum(a)codeweavers.com> wrote:
Austin English wrote:
If no one opposes in the next few days I'll add it/start tagging bugs. I'm no more opposed to adding a pseudo-component. I simply suggest naming it unknown-audio or unknown-sound instead of "sound" such that people will hopefully still use the existing quartz, mmdevapi, winealsa, winmm&mci, direct-dmusic and direct-dsound.
How is that better than simple 'unknown'?
Because then I can search for audio-related bugs where the component is not yet known.
If the component is unknown probably there is no need to speculate about the reasons and the source of the bug and investigate the problem instead? -- Dmitry.
On Fri, Jan 20, 2012 at 10:40:53PM +0800, Dmitry Timoshkov wrote:
Andrew Eikum <aeikum(a)codeweavers.com> wrote:
Austin English wrote:
If no one opposes in the next few days I'll add it/start tagging bugs. I'm no more opposed to adding a pseudo-component. I simply suggest naming it unknown-audio or unknown-sound instead of "sound" such that people will hopefully still use the existing quartz, mmdevapi, winealsa, winmm&mci, direct-dmusic and direct-dsound.
How is that better than simple 'unknown'?
Because then I can search for audio-related bugs where the component is not yet known.
If the component is unknown probably there is no need to speculate about the reasons and the source of the bug and investigate the problem instead?
I can't investigate the problem if I don't know about it ;) If a bug is audio related, I want to know about it. I've been asking people to CC me on audio bugs, but that gets missed on a lot of them. Adding a Sound keyword would make searching for audio bugs trivial, so I can add myself to the CC list. Andrew
Andrew Eikum <aeikum(a)codeweavers.com> wrote:
Because then I can search for audio-related bugs where the component is not yet known.
If the component is unknown probably there is no need to speculate about the reasons and the source of the bug and investigate the problem instead?
I can't investigate the problem if I don't know about it ;)
If a bug is audio related, I want to know about it. I've been asking people to CC me on audio bugs, but that gets missed on a lot of them. Adding a Sound keyword would make searching for audio bugs trivial, so I can add myself to the CC list.
If the problem is sound related there are usually some known words in the summary line describing the problem, why not search for them? Why do you think inventing a new keyword and adding it to the buch of bugs is easier that correctly formulate the problem using right words in the summary? -- Dmitry.
On 20 January 2012 17:25, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
If the problem is sound related there are usually some known words in the summary line describing the problem, why not search for them? Why do you think inventing a new keyword and adding it to the buch of bugs is easier that correctly formulate the problem using right words in the summary?
Well, at least searching is easier for a well defined keyword than for a free form summary line. With a keyword you wouldn't have to take into account differences in formulation like e.g. "audio" vs. "sound". That aside, it does seem to me that there's some overlap in functionality between keywords and components. I'm not quite sure how other people use the component field, but maybe we don't need both. Somewhat related, is it really useful to make the distinction between mmdevapi, winmm, dsound, etc. if it's mostly the same people working on those, and you practically need to debug a bug first before you can make that distinction anyway?
Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 20 January 2012 17:25, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
If the problem is sound related there are usually some known words in the summary line describing the problem, why not search for them? Why do you think inventing a new keyword and adding it to the buch of bugs is easier that correctly formulate the problem using right words in the summary?
Well, at least searching is easier for a well defined keyword than for a free form summary line. With a keyword you wouldn't have to take into account differences in formulation like e.g. "audio" vs. "sound".
Well, it's not that hard to have an agreement what "right" words to use. A person able to add a keyword also should be able to correct the summary according to "established standards".
That aside, it does seem to me that there's some overlap in functionality between keywords and components. I'm not quite sure how other people use the component field, but maybe we don't need both. Somewhat related, is it really useful to make the distinction between mmdevapi, winmm, dsound, etc. if it's mostly the same people working on those, and you practically need to debug a bug first before you can make that distinction anyway?
It's easier for simple cases like crashes or regressions to set the component, and I agree that adding keywords duplicating components should be discouraged, and 'printing' is among of them. -- Dmitry.
On Fri, Jan 20, 2012 at 11:04, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 20 January 2012 17:25, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
If the problem is sound related there are usually some known words in the summary line describing the problem, why not search for them? Why do you think inventing a new keyword and adding it to the buch of bugs is easier that correctly formulate the problem using right words in the summary?
Well, at least searching is easier for a well defined keyword than for a free form summary line. With a keyword you wouldn't have to take into account differences in formulation like e.g. "audio" vs. "sound".
Well, it's not that hard to have an agreement what "right" words to use. A person able to add a keyword also should be able to correct the summary according to "established standards".
That aside, it does seem to me that there's some overlap in functionality between keywords and components. I'm not quite sure how other people use the component field, but maybe we don't need both. Somewhat related, is it really useful to make the distinction between mmdevapi, winmm, dsound, etc. if it's mostly the same people working on those, and you practically need to debug a bug first before you can make that distinction anyway?
It's easier for simple cases like crashes or regressions to set the component, and I agree that adding keywords duplicating components should be discouraged, and 'printing' is among of them.
I'd be okay with removing printing, the component will obviously be wineps.drv or gdi32 for any printing bug (besides there aren't all that many printing bugs, and it's not seeing much activity). -- -Austin
On 01/20/2012 12:45 PM, Austin English wrote:
On Fri, Jan 20, 2012 at 11:04, Dmitry Timoshkov<dmitry(a)baikal.ru> wrote:
Henri Verbeet<hverbeet(a)gmail.com> wrote:
On 20 January 2012 17:25, Dmitry Timoshkov<dmitry(a)baikal.ru> wrote:
If the problem is sound related there are usually some known words in the summary line describing the problem, why not search for them? Why do you think inventing a new keyword and adding it to the buch of bugs is easier that correctly formulate the problem using right words in the summary?
Well, at least searching is easier for a well defined keyword than for a free form summary line. With a keyword you wouldn't have to take into account differences in formulation like e.g. "audio" vs. "sound".
Well, it's not that hard to have an agreement what "right" words to use. A person able to add a keyword also should be able to correct the summary according to "established standards".
That aside, it does seem to me that there's some overlap in functionality between keywords and components. I'm not quite sure how other people use the component field, but maybe we don't need both. Somewhat related, is it really useful to make the distinction between mmdevapi, winmm, dsound, etc. if it's mostly the same people working on those, and you practically need to debug a bug first before you can make that distinction anyway?
It's easier for simple cases like crashes or regressions to set the component, and I agree that adding keywords duplicating components should be discouraged, and 'printing' is among of them.
I'd be okay with removing printing, the component will obviously be wineps.drv or gdi32 for any printing bug (besides there aren't all that many printing bugs, and it's not seeing much activity).
IMHO, it should be an additional component sound-general, or sound-unknown, or better yet "unknown-sound". There are many areas like that, that require investigation by a person with knowledge of said area to properly set component. With Wine growing we can't require every developer to peruse all bugs in bugzilla all the time. And searching for some specific bugs by their subject almost never returns correct component. Case in point - right now we have 4468 bugs assigned to the unknown component. How many people actually go over those in attempt to investigate and set correct component? While keywords & components overlap, more generic components will not overlap with specific ones. And if we name all of them "unknown-something" that will help user / bugzilla triage people to pick closer area for SMEs to do more detailed investigation. To begin with I propose to create following components: unknown-browser unknown-core unknown-d3d unknown-gui unknown-input unknown-printing unknown-sound Probably forgot a few. For triagers reassign bugs to area that looks close to the problem, unless exact issue is known. For SMEs (Subject Matter Experts) to look through bugs in their general area and reassign to more appropriate component. Vitaliy.
On 21 January 2012 03:48, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
IMHO, it should be an additional component sound-general, or sound-unknown, or better yet "unknown-sound". There are many areas like that, that require investigation by a person with knowledge of said area to properly set component.
Yes, but I'd argue we don't really need anything more specific than those general / unknown components. For something the size of the kernel having more specific components probably makes sense, but realistically, if a specific area in Wine has more than 2-3 persons working on it it's considered large. Taking D3D as an example, much as I'd perhaps like to, if I put in the effort of downloading a demo, reproducing the bug, looking through the log etc., I'm not going to set a more specific component and abandon the bug thinking "Oh well, someone else's problem." if I find out the problem is in ddraw instead of core wined3d. When that kind of thing happens at all, it's usually because of not having the hardware or software required to reproduce the bug. Note however that even with coarse components like that you still won't necessarily be able to tell from the description alone if e.g. an application freezing with a black screen happens because of a bug in d3d, some x11drv issue, a networking problem or wineserver getting stuck in a loop, etc. Personally, it doesn't bother me that much if someone makes a plausible guess in cases like that, essentially just asking someone more familiar with that kind of problem to take a look.
To begin with I propose to create following components: unknown-browser unknown-core unknown-d3d unknown-gui unknown-input unknown-printing unknown-sound
In case of "unknown-d3d" at least, that would really just be renaming the current directx-d3d component. There used to be a directx-ddraw component as well, but we merged it with directx-d3d because it really didn't add anything useful.
* On Fri, 20 Jan 2012, Vitaliy Margolen wrote:
While keywords & components overlap, more generic components will not overlap with specific ones. And if we name all of them "unknown-something" that will help user / bugzilla triage people to pick closer area for SMEs to do more detailed investigation.
To begin with I propose to create following components: unknown-browser unknown-core unknown-d3d unknown-gui unknown-input unknown-printing unknown-sound
Yes, I support the idea very much. S.
Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
While keywords & components overlap, more generic components will not overlap with specific ones. And if we name all of them "unknown-something" that will help user / bugzilla triage people to pick closer area for SMEs to do more detailed investigation.
To begin with I propose to create following components: unknown-browser unknown-core unknown-d3d unknown-gui unknown-input unknown-printing unknown-sound
Yes, I support the idea very much.
Sorry, but honestly, in order to support an idea if adding/changing something in Wine bugzilla one should spend several months actively triaging bugs first. Personally to me, adding a bunch of unknown-* components will just needlessly clutter the components list, it's already too big. -- Dmitry.
I think that's the point Henri was trying to make. Most of these components are useless. Sure, you *can* pinpoint every component down, but as Henri said, if you do that, what's most likely to happen is you end up writing a patch. It's probably worth checking every category and remove the ones with less than 5-10 open bugs. J. Leclanche On Sat, Jan 21, 2012 at 5:01 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
While keywords & components overlap, more generic components will not overlap with specific ones. And if we name all of them "unknown-something" that will help user / bugzilla triage people to pick closer area for SMEs to do more detailed investigation.
To begin with I propose to create following components: unknown-browser unknown-core unknown-d3d unknown-gui unknown-input unknown-printing unknown-sound
Yes, I support the idea very much.
Sorry, but honestly, in order to support an idea if adding/changing something in Wine bugzilla one should spend several months actively triaging bugs first.
Personally to me, adding a bunch of unknown-* components will just needlessly clutter the components list, it's already too big.
-- Dmitry.
On 01/21/2012 10:07 AM, Jerome Leclanche wrote:
I think that's the point Henri was trying to make. Most of these components are useless.
Sure, you *can* pinpoint every component down, but as Henri said, if you do that, what's most likely to happen is you end up writing a patch.
It's probably worth checking every category and remove the ones with less than 5-10 open bugs.
First of all jerome, would you respect everyone and do a bottom posting on this mailing list. Otherwise people will just ignore everything you said. If you can't fix your mailer - use a different one. It's not an excuse to disrespect everyone else on this list. On 01/21/2012 10:01 AM, Dmitry Timoshkov wrote:
Sorry, but honestly, in order to support an idea if adding/changing something in Wine bugzilla one should spend several months actively triaging bugs first.
I've spent enough time doing so and can tell that you are the first person to move _all bugs_ to "unknown" component. And leave them there. And that all developers can't be expected to read every single bug and try to understand if it's a bug in their area or not. The whole point of triaging bugs is to collect enough data for a person(s) familiar with the general area to do a followup investigation and eventually fix the bug. Without knowing the area it's a waste of time for everyone to do investigation on _every single_ new bug. One can't go just by bug subject - in most cases it's not accurate enough or outright misleading. Same for the content, logs, etc. Vitaliy.
On Sat, Jan 21, 2012 at 6:22 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com>wrote:
On 01/21/2012 10:07 AM, Jerome Leclanche wrote:
I think that's the point Henri was trying to make. Most of these components are useless.
Sure, you *can* pinpoint every component down, but as Henri said, if you do that, what's most likely to happen is you end up writing a patch.
It's probably worth checking every category and remove the ones with less than 5-10 open bugs.
First of all jerome, would you respect everyone and do a bottom posting on this mailing list. Otherwise people will just ignore everything you said. If you can't fix your mailer - use a different one. It's not an excuse to disrespect everyone else on this list.
Calm down Vitaliy, just because I'm using Gmail's web client doesn't mean I hate you and am a terrorist or something. I started this thread to ask for comments, the last thing I would do is disrespect people answering to it.
Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
I've spent enough time doing so and can tell that you are the first person to move _all bugs_ to "unknown" component. And leave them there.
That's a gratuitous conclusion, where did get that idea?
And that all developers can't be expected to read every single bug and try to understand if it's a bug in their area or not.
Not all developers are subscribed to wine-bugs, and even subscribed are not expected to read all the bug reports.
The whole point of triaging bugs is to collect enough data for a person(s) familiar with the general area to do a followup investigation and eventually fix the bug. Without knowing the area it's a waste of time for everyone to do investigation on _every single_ new bug.
In general yes, but it's not always possible for every bug to set the correct component without an investigation done by a developer.
One can't go just by bug subject - in most cases it's not accurate enough or outright misleading. Same for the content, logs, etc.
That's why there are also component and keywords fields. -- Dmitry.
participants (8)
-
Andrew Eikum -
Austin English -
Dmitry Timoshkov -
Henri Verbeet -
Jerome Leclanche -
Joerg-Cyril.Hoehle＠t-systems.com -
Saulius Krasuckas -
Vitaliy Margolen