"Sound" keyword on bugzilla

[Jerome Leclanche]

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

[Jerome Leclanche]

Any comments?

J. Leclanche

On Tue, Jan 17, 2012 at 1:09 AM, Jerome Leclanche  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

[Andrew Eikum]

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  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
>

[Austin English]

On Wed, Jan 18, 2012 at 13:25, Andrew Eikum  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  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.

[Dmitry Timoshkov]

Austin English  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.

[Jerome Leclanche]

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  wrote:
> Austin English  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.

[Dmitry Timoshkov]

Jerome Leclanche  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.

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@winehq -- useless waste of space.

BTW, can I rename one of my saved searches?

Thank you,
    Jörg Höhle

[Jerome Leclanche]

On Fri, Jan 20, 2012 at 9:49 AM,  wrote:
> BTW, can I rename one of my saved searches?

Saving it as a different name (at the bottom of the page) does the trick.
> Thank you,
>        Jörg Höhle

J. Leclanche

[Dmitry Timoshkov]

[e-mail] 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?

[Andrew Eikum]

On Fri, Jan 20, 2012 at 07:23:42PM +0800, Dmitry Timoshkov wrote:
> [e-mail] 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.

[Dmitry Timoshkov]

Andrew Eikum  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?

[Andrew Eikum]

On Fri, Jan 20, 2012 at 10:40:53PM +0800, Dmitry Timoshkov wrote:
> Andrew Eikum  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

[Dmitry Timoshkov]

Andrew Eikum  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?

[Henri Verbeet]

On 20 January 2012 17:25, Dmitry Timoshkov  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?

[Dmitry Timoshkov]

Henri Verbeet  wrote:
> On 20 January 2012 17:25, Dmitry Timoshkov  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.

[Austin English]

On Fri, Jan 20, 2012 at 11:04, Dmitry Timoshkov  wrote:
> Henri Verbeet  wrote:
> > On 20 January 2012 17:25, Dmitry Timoshkov  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).

[Vitaliy Margolen]

On 01/20/2012 12:45 PM, Austin English wrote:
> On Fri, Jan 20, 2012 at 11:04, Dmitry Timoshkov  wrote:
> > Henri Verbeet  wrote:
> > > On 20 January 2012 17:25, Dmitry Timoshkov  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.

[Henri Verbeet]

On 21 January 2012 03:48, Vitaliy Margolen  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.

[Saulius Krasuckas]

* 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.

[Dmitry Timoshkov]

Saulius Krasuckas  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.

[Jerome Leclanche]

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  wrote:
> Saulius Krasuckas  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.

[Vitaliy Margolen]

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.

[Jerome Leclanche]

On Sat, Jan 21, 2012 at 6:22 PM, Vitaliy Margolen
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.

[Dmitry Timoshkov]

Vitaliy Margolen  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.