5:13 p.m.
== Members Present ==
* Jon Stanley (jds2001)
* Kevin Fenzi (nirik)
* Dan Horak (sharkcz)
* Josh Boyer (jwb)
* Brian Pepple (bpepple)
* David Woodhouse (dwmw2)
* Dennis Gilmore (dgilmore)
== Members Absent ==
* Bill Nottingham (notting)
* Jarod Wilson (j-rod)
== Sponsor request - mmahut ==
This request was approved.
== Sponsor request - s4504kr ==
This request was approved.
== Sponsor request - peter ==
This request was approved.
== Sponsor request - jussilehtola ==
This request was approved after some discussion about what changes are
appropriate to make for a reviewer in a Merge review.
== Provenpackager request - lennart ==
This request was approved.
== PulseAudio regression handling ==
Long and contentious discussion about concerns with the VolumeControl
feature. FESCo decided to get gnome-alsamixer packaged and added to the
default desktop live/install spins to allow users whos use cases are
not covered currently by VolumeControl to have a GUI way to adjust
mixer settings. Hopefully this will be dropped/revisited in F12.
== IRC LOG ==
Log posted at: https://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24
6:28 p.m.
On 04/24/2009 03:13 PM, Kevin Fenzi wrote:
== PulseAudio regression handling ==
Long and contentious discussion about concerns with the VolumeControl
feature. FESCo decided to get gnome-alsamixer packaged and added to the
default desktop live/install spins to allow users whos use cases are
not covered currently by VolumeControl to have a GUI way to adjust
mixer settings. Hopefully this will be dropped/revisited in F12.
Wearing my Board hat, I'll give a quick history lesson: changes were
mandated to codeina a few releases ago post feature freeze. The changes
would have made codeina more acceptable for Fedora's stance on freedom,
however that change was reversed by the board because it was mandated
post feature freeze, and it was agreed future mandates, if any, would
come down pre-feature freeze, but we should not be in the business of
giving mandates.
So, can someone tell me how mandating this is more important than
mandating Fedora be free, and why this decree should not be reversed?
Do I really need to bring this up at the next board meeting?
6:36 p.m.
On Fri, 2009-04-24 at 16:28 -0700, Christopher Aillon wrote:
On 04/24/2009 03:13 PM, Kevin Fenzi wrote:
> == PulseAudio regression handling ==
>
> Long and contentious discussion about concerns with the VolumeControl
> feature. FESCo decided to get gnome-alsamixer packaged and added to the
> default desktop live/install spins to allow users whos use cases are
> not covered currently by VolumeControl to have a GUI way to adjust
> mixer settings. Hopefully this will be dropped/revisited in F12.
Wearing my Board hat, I'll give a quick history lesson: changes were
mandated to codeina a few releases ago post feature freeze. The changes
would have made codeina more acceptable for Fedora's stance on freedom,
however that change was reversed by the board because it was mandated
post feature freeze, and it was agreed future mandates, if any, would
come down pre-feature freeze, but we should not be in the business of
giving mandates.
So, can someone tell me how mandating this is more important than
mandating Fedora be free, and why this decree should not be reversed?
Do I really need to bring this up at the next board meeting?
If they can't mandate this then I suspect the only option left is to
enact the contingency plan, which neither party seems to want to happen.
So I'm not sure I see the point in you forcing any point.
Dave.
6:41 p.m.
On 04/24/2009 04:36 PM, Dave Airlie wrote:
If they can't mandate this then I suspect the only option left is
to
enact the contingency plan, which neither party seems to want to happen.
So I'm not sure I see the point in you forcing any point.
The plan is as designed per the feature page. Just some people decided
post-freeze that they don't like it.
6:52 p.m.
On Fri, 2009-04-24 at 16:41 -0700, Christopher Aillon wrote:
On 04/24/2009 04:36 PM, Dave Airlie wrote:
> If they can't mandate this then I suspect the only option left is to
> enact the contingency plan, which neither party seems to want to happen.
>
> So I'm not sure I see the point in you forcing any point.
The plan is as designed per the feature page. Just some people decided
post-freeze that they don't like it.
Or rather didn't fully understand the limited scope of coverage for F11.
FESCo isn't mandating anything. In fact after a long and (un)healthy
discussion, a compromise for the sake of F11 was reached, one that
doesn't require any changes to existing software, only the addition of
one package. Comparing it to the Codina fiasco isn't exactly fair.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7:15 p.m.
On 04/24/2009 04:52 PM, Jesse Keating wrote:
On Fri, 2009-04-24 at 16:41 -0700, Christopher Aillon wrote:
> On 04/24/2009 04:36 PM, Dave Airlie wrote:
>> If they can't mandate this then I suspect the only option left is to
>> enact the contingency plan, which neither party seems to want to happen.
>>
>> So I'm not sure I see the point in you forcing any point.
> The plan is as designed per the feature page. Just some people decided
> post-freeze that they don't like it.
Or rather didn't fully understand the limited scope of coverage for F11.
FESCo isn't mandating anything. In fact after a long and (un)healthy
discussion, a compromise for the sake of F11 was reached, one that
doesn't require any changes to existing software, only the addition of
one package.
A compromise works best if both parties are on board. I don't believe
that the desktop guys will object to the package existing and being
installable if people want. No CLI needed since we have GUI install
tools. The objection is with the mandate for it to be installed by
default on the desktop live/install spins.
7:40 p.m.
On Fri, 2009-04-24 at 17:15 -0700, Christopher Aillon wrote:
A compromise works best if both parties are on board. I don't
believe
that the desktop guys will object to the package existing and being
installable if people want. No CLI needed since we have GUI install
tools. The objection is with the mandate for it to be installed by
default on the desktop live/install spins.
See, the Desktop team has no say in whether or not a graphical mixer is
available in Fedora. The middle ground between reverting the mixer
feature all together and leaving at is it is having a graphical mixer
installed by default available in the menus. That was the compromise.
If the Desktop team really feels like this wasn't a compromise and it
was something mandated and forced, they can raise it to the board level
if they wish.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7:51 p.m.
On Fri, 2009-04-24 at 17:40 -0700, Jesse Keating wrote:
On Fri, 2009-04-24 at 17:15 -0700, Christopher Aillon wrote:
> A compromise works best if both parties are on board. I don't believe
> that the desktop guys will object to the package existing and being
> installable if people want. No CLI needed since we have GUI install
> tools. The objection is with the mandate for it to be installed by
> default on the desktop live/install spins.
See, the Desktop team has no say in whether or not a graphical mixer is
available in Fedora. The middle ground between reverting the mixer
feature all together and leaving at is it is having a graphical mixer
installed by default available in the menus. That was the compromise.
If the Desktop team really feels like this wasn't a compromise and it
was something mandated and forced, they can raise it to the board level
if they wish.
The mandate is for both Desktop/LiveCD spin and Fedora default install,
surely the Desktop team does decide for the desktop/livecd spin, but not
or the Fedora install. Since I'm sure the KDE spin won't want to include
either of these.
Dave.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
8:12 p.m.
Dave Airlie wrote:
On Fri, 2009-04-24 at 17:40 -0700, Jesse Keating wrote:
> See, the Desktop team has no say in whether or not a graphical mixer is
> available in Fedora. The middle ground between reverting the mixer
> feature all together and leaving at is it is having a graphical mixer
> installed by default available in the menus. That was the compromise.
The mandate is for both Desktop/LiveCD spin and Fedora default install,
surely the Desktop team does decide for the desktop/livecd spin, but not
or the Fedora install. Since I'm sure the KDE spin won't want to include
either of these.
Jesse was replying to this:
A compromise works best if both parties are on board. I don't
believe
that the desktop guys will object to the package existing and being
installable if people want.
In that context he's saying that "the package existing and being
installable" is not something that the Desktop team has a say over. So
saying that they wouldn't block that from happening is not a compromise.
It's how things would have been without a compromise.
-Toshio
4:57 a.m.
Dave Airlie wrote:
The mandate is for both Desktop/LiveCD spin and Fedora default
install,
surely the Desktop team does decide for the desktop/livecd spin, but not
or the Fedora install. Since I'm sure the KDE spin won't want to include
either of these.
The KDE spin includes KMix which gives access to all the ALSA settings as it
always did, so it is not affected by this debate at all. This discussion is
only about GNOME.
Kevin Kofler
8:48 p.m.
On 04/24/2009 05:40 PM, Jesse Keating wrote:
On Fri, 2009-04-24 at 17:15 -0700, Christopher Aillon wrote:
> A compromise works best if both parties are on board. I don't believe
> that the desktop guys will object to the package existing and being
> installable if people want. No CLI needed since we have GUI install
> tools. The objection is with the mandate for it to be installed by
> default on the desktop live/install spins.
See, the Desktop team has no say in whether or not a graphical mixer is
available in Fedora. The middle ground between reverting the mixer
feature all together and leaving at is it is having a graphical mixer
installed by default available in the menus. That was the compromise.
If the Desktop team really feels like this wasn't a compromise and it
was something mandated and forced, they can raise it to the board level
if they wish.
To make it clearer:
Before today's FESCo meeting:
* The old mixer was removed
* 1 mixer installed by default in the desktop spin.
* The old mixer could not be installed via PK or yum
Today's FESCO Mandate:
* Revive the old mixer
* Ship 2 mixers by default in the desktop spin.
Compromise seems like it would be something along the lines of:
* Revive the old mixer
* 1 mixer installed by default in the desktop spin
* The old mixer can be installed via PK or yum
9:09 p.m.
On Fri, 2009-04-24 at 18:48 -0700, Christopher Aillon wrote:
<snip>
To make it clearer:
Before today's FESCo meeting:
* The old mixer was removed
* 1 mixer installed by default in the desktop spin.
* The old mixer could not be installed via PK or yum
Today's FESCO Mandate:
* Revive the old mixer
* Ship 2 mixers by default in the desktop spin.
Compromise seems like it would be something along the lines of:
* Revive the old mixer
* 1 mixer installed by default in the desktop spin
* The old mixer can be installed via PK or yum
FYI, Adam didn't revive the old mixer (that is still in gnome-media, but
disabled), he revived gnome-alsamixer, another GNOME ALSA mixer with no
upstream.
The URL mentioned in the spec file[1] says:
"The page cannot be found"
If the thing is going to get installed by default, you should at _least_
package up the old gnome-volume-control. Otherwise, yes, I'll be a pain
and drag this to the board.
[1]: http://www.paw.co.za/projects/gnome-alsamixer/
1:22 a.m.
On Sat, 2009-04-25 at 03:09 +0100, Bastien Nocera wrote:
FYI, Adam didn't revive the old mixer (that is still in
gnome-media, but
disabled), he revived gnome-alsamixer, another GNOME ALSA mixer with no
upstream.
It does have one; it's part of GNOME's git. The git checkout command is
included as a comment right at the top of the spec.
The URL mentioned in the spec file[1] says:
"The page cannot be found"
Sorry, I'll adjust that.
If the thing is going to get installed by default, you should at
_least_
package up the old gnome-volume-control. Otherwise, yes, I'll be a pain
and drag this to the board.
My thinking on that is explained in the bug report. I'd say the old
g-v-c has less of an upstream, because the old g-v-c effectively doesn't
exist anywhere except in history. Where could it get developed in
future, if we wanted to push some changes upstream? The new g-v-c is
effectively a completely different application, it doesn't count as
'upstream' for the old g-v-c any more. I don't think you'd be accepting
patches for the *old* g-v-c into the *new* one :)
gnome-alsamixer exists as a module in GNOME git. Hence if we're correct
in identifying a demand for a full-access mixer in GNOME,
gnome-alsamixer is in fact the project which could more easily be
resurrected as a proper upstream application. It'd be rather hard to do
that for the old g-v-c - it would have to be changed to be identified as
something completely different from the *new* g-v-c.
I'm not particularly attached to this logic, though. If everyone agrees
the old g-v-c is the way to go I'm fine with that, as I said all I
really wanted is a full-access mixer in the default install.
--
Adam Williamson <awilliam(a)redhat.com>
Red Hat
1:59 a.m.
On Fri, 2009-04-24 at 23:22 -0700, Adam Williamson wrote:
On Sat, 2009-04-25 at 03:09 +0100, Bastien Nocera wrote:
> FYI, Adam didn't revive the old mixer (that is still in gnome-media, but
> disabled), he revived gnome-alsamixer, another GNOME ALSA mixer with no
> upstream.
It does have one; it's part of GNOME's git. The git checkout command is
included as a comment right at the top of the spec.
> The URL mentioned in the spec file[1] says:
> "The page cannot be found"
Sorry, I'll adjust that.
> If the thing is going to get installed by default, you should at _least_
> package up the old gnome-volume-control. Otherwise, yes, I'll be a pain
> and drag this to the board.
My thinking on that is explained in the bug report. I'd say the old
g-v-c has less of an upstream, because the old g-v-c effectively doesn't
exist anywhere except in history. Where could it get developed in
future, if we wanted to push some changes upstream? The new g-v-c is
effectively a completely different application, it doesn't count as
'upstream' for the old g-v-c any more. I don't think you'd be accepting
patches for the *old* g-v-c into the *new* one :)
gnome-alsamixer exists as a module in GNOME git. Hence if we're correct
in identifying a demand for a full-access mixer in GNOME,
gnome-alsamixer is in fact the project which could more easily be
resurrected as a proper upstream application. It'd be rather hard to do
that for the old g-v-c - it would have to be changed to be identified as
something completely different from the *new* g-v-c.
I'm not particularly attached to this logic, though. If everyone agrees
the old g-v-c is the way to go I'm fine with that, as I said all I
really wanted is a full-access mixer in the default install.
I took a quick look at this, and gnome-media has the code moved to the
gst-mixer subdir, but thats it, the code still believes its called
g-v-c, all the files are called that, the gconf schema keys, the
desktop, etc.
So I suspect the effort to do that vs ship gnome-alsamixer at this point
in the development cycle isn't going to provide any useful advantages to
the advanced sound configuration people are requiring. Like it the
answer to the question is otherwise run a cli app called alsamixer, I'd
ship a kde app quicker :)
Dave.
7:46 a.m.
On Fri, 2009-04-24 at 23:22 -0700, Adam Williamson wrote:
On Sat, 2009-04-25 at 03:09 +0100, Bastien Nocera wrote:
> FYI, Adam didn't revive the old mixer (that is still in gnome-media, but
> disabled), he revived gnome-alsamixer, another GNOME ALSA mixer with no
> upstream.
It does have one; it's part of GNOME's git. The git checkout command is
included as a comment right at the top of the spec.
Oh, code is available. Last code check-in was 4 years ago:
http://git.gnome.org/cgit/gnome-alsamixer/tree/ChangeLog
> The URL mentioned in the spec file[1] says:
> "The page cannot be found"
Sorry, I'll adjust that.
> If the thing is going to get installed by default, you should at _least_
> package up the old gnome-volume-control. Otherwise, yes, I'll be a pain
> and drag this to the board.
My thinking on that is explained in the bug report. I'd say the old
g-v-c has less of an upstream, because the old g-v-c effectively doesn't
exist anywhere except in history.
It's in the gst-mixer sub-dir of gnome-media:
http://git.gnome.org/cgit/gnome-media/tree/gst-mixer
It's still the volume control for systems that don't have PulseAudio
like Solaris or *BSDs.
Where could it get developed in
future, if we wanted to push some changes upstream? The new g-v-c is
effectively a completely different application, it doesn't count as
'upstream' for the old g-v-c any more. I don't think you'd be accepting
patches for the *old* g-v-c into the *new* one :)
No, but Brian Cameron is maintaining the old gnome-volume-control.
gnome-alsamixer exists as a module in GNOME git. Hence if we're
correct
in identifying a demand for a full-access mixer in GNOME,
gnome-alsamixer is in fact the project which could more easily be
resurrected as a proper upstream application. It'd be rather hard to do
that for the old g-v-c - it would have to be changed to be identified as
something completely different from the *new* g-v-c.
I'm not particularly attached to this logic, though. If everyone agrees
the old g-v-c is the way to go I'm fine with that, as I said all I
really wanted is a full-access mixer in the default install.
--
Adam Williamson <awilliam(a)redhat.com>
Red Hat
12:30 p.m.
On Sat, 2009-04-25 at 13:46 +0100, Bastien Nocera wrote:
> It does have one; it's part of GNOME's git. The git checkout command is
> included as a comment right at the top of the spec.
Oh, code is available. Last code check-in was 4 years ago:
http://git.gnome.org/cgit/gnome-alsamixer/tree/ChangeLog
Oh, yeah - I did look at the last checkin dates but didn't notice they
were all translations.
> My thinking on that is explained in the bug report. I'd say
the old
> g-v-c has less of an upstream, because the old g-v-c effectively doesn't
> exist anywhere except in history.
It's in the gst-mixer sub-dir of gnome-media:
http://git.gnome.org/cgit/gnome-media/tree/gst-mixer
It's still the volume control for systems that don't have PulseAudio
like Solaris or *BSDs.
> Where could it get developed in
> future, if we wanted to push some changes upstream? The new g-v-c is
> effectively a completely different application, it doesn't count as
> 'upstream' for the old g-v-c any more. I don't think you'd be
accepting
> patches for the *old* g-v-c into the *new* one :)
No, but Brian Cameron is maintaining the old gnome-volume-control.
Those are all good points - as long as the issues Dave Airlie brought up
(about how it still identifies itself as g-v-c and hence would
presumably conflict if both were installed at once) are addressed, I'm
perfectly happy for the old g-v-c to be used instead. Should we start
filing bugs for Brian?
--
Adam Williamson <awilliam(a)redhat.com>
Red Hat
2:33 p.m.
On Sat, 2009-04-25 at 10:30 -0700, Adam Williamson wrote:
On Sat, 2009-04-25 at 13:46 +0100, Bastien Nocera wrote:
<snip>
Those are all good points - as long as the issues Dave Airlie brought
up
(about how it still identifies itself as g-v-c and hence would
presumably conflict if both were installed at once) are addressed, I'm
perfectly happy for the old g-v-c to be used instead. Should we start
filing bugs for Brian?
Well, you'd need to do a bit of work on the spec file, but there's
nothing there that wouldn't be straight forward.
You'd need to remove all the bits you're not interested about (most of
them should be disable-able through configure switches), rename the
binary (and binary name in the desktop file, and schemas), and change
the GETTEXT_PACKAGE so it doesn't conflict with gnome-media.
2:41 p.m.
On Sat, 2009-04-25 at 20:33 +0100, Bastien Nocera wrote:
On Sat, 2009-04-25 at 10:30 -0700, Adam Williamson wrote:
> On Sat, 2009-04-25 at 13:46 +0100, Bastien Nocera wrote:
<snip>
> Those are all good points - as long as the issues Dave Airlie brought up
> (about how it still identifies itself as g-v-c and hence would
> presumably conflict if both were installed at once) are addressed, I'm
> perfectly happy for the old g-v-c to be used instead. Should we start
> filing bugs for Brian?
Well, you'd need to do a bit of work on the spec file, but there's
nothing there that wouldn't be straight forward.
You'd need to remove all the bits you're not interested about (most of
them should be disable-able through configure switches), rename the
binary (and binary name in the desktop file, and schemas), and change
the GETTEXT_PACKAGE so it doesn't conflict with gnome-media.
OK. I'll probably be able to look at that Monday, I'll be too busy at
the conference for today and tomorrow.
--
Adam Williamson <awilliam(a)redhat.com>
Red Hat
6:20 p.m.
On Sat, 2009-04-25 at 20:33 +0100, Bastien Nocera wrote:
On Sat, 2009-04-25 at 10:30 -0700, Adam Williamson wrote:
> On Sat, 2009-04-25 at 13:46 +0100, Bastien Nocera wrote:
<snip>
> Those are all good points - as long as the issues Dave Airlie brought up
> (about how it still identifies itself as g-v-c and hence would
> presumably conflict if both were installed at once) are addressed, I'm
> perfectly happy for the old g-v-c to be used instead. Should we start
> filing bugs for Brian?
Well, you'd need to do a bit of work on the spec file, but there's
nothing there that wouldn't be straight forward.
You'd need to remove all the bits you're not interested about (most of
them should be disable-able through configure switches), rename the
binary (and binary name in the desktop file, and schemas), and change
the GETTEXT_PACKAGE so it doesn't conflict with gnome-media.
Doesn't seem to be quite so straightforward. I've done the above and got
it to build and mostly work, but it's still buggy. Here's the SRPM:
http://adamwill.fedorapeople.org/gst-mixer-2.26.0-2.aw_fc11.src.rpm
if you switch from one device to another and back again, it stops
showing any tab but the 'Sound Theme' tab. Must be some kind of
configuration info being lost somehow by the name change, I guess? I
can't figure it out exactly, though.
Also note that some icons are missing, I guess it's looking for them in
the wrong place somehow. Can't figure that out either.
If anyone can fix these issues it'd be appreciated.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:51 p.m.
On Mon, 2009-04-27 at 16:20 -0700, Adam Williamson wrote:
Doesn't seem to be quite so straightforward. I've done the
above and got
it to build and mostly work, but it's still buggy. Here's the SRPM:
http://adamwill.fedorapeople.org/gst-mixer-2.26.0-2.aw_fc11.src.rpm
if you switch from one device to another and back again, it stops
showing any tab but the 'Sound Theme' tab. Must be some kind of
configuration info being lost somehow by the name change, I guess? I
can't figure it out exactly, though.
Actually, this bug appears to be:
https://bugs.launchpad.net/ubuntu/+source/gnome-media/+bug/345645
http://bugzilla.gnome.org/show_bug.cgi?id=576022
I'll look into that later...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:47 a.m.
On Sat, Apr 25, 2009 at 4:09 AM, Bastien Nocera <bnocera(a)redhat.com> wrote:
On Fri, 2009-04-24 at 18:48 -0700, Christopher Aillon wrote:
<snip>
If the thing is going to get installed by default, you should at
_least_
package up the old gnome-volume-control.
This would make the user experience _worse_ for people updating from
F9/10 -> F11 as they won't have the new mixer unless they install it
by hand.
9:30 p.m.
Christopher Aillon wrote:
To make it clearer:
Before today's FESCo meeting:
* The old mixer was removed
* 1 mixer installed by default in the desktop spin.
* The old mixer could not be installed via PK or yum
Today's FESCO Mandate:
* Revive the old mixer
* Ship 2 mixers by default in the desktop spin.
Compromise seems like it would be something along the lines of:
* Revive the old mixer
* 1 mixer installed by default in the desktop spin
* The old mixer can be installed via PK or yum
I'm afraid what you're diagraming has nothing to do with compromise.
The diagram you draw implies that the level of compromise depends on how
much has changed state in the distro between the first step and last
step. By that logic, this would be a better compromise than what
actually happened:
Before today's FESCo meeting:
* The old mixer was removed
* 1 mixer installed by default in the desktop spin.
* XFCE, KDE, N Other mixers available via PK or yum
Today's FESCo Mandate:
* Ship new mixers by default in the desktop spin.
* Ship KDE mixer by default in the desktop spin.
This makes only one change just like your compromise.
What's really involved in compromise is how far each party moves from
their original positions from the beginning of the process:
Pre meeting FESCo
* new mixer is not sufficient to meet many user's needs
- put alternative graphical mixer onto the default spin
- add a button to the new mixer to invoke the alternate
Pre meeting desktop Team
* New mixer is sufficient for all but a few pro user's needs.
- 1 new mixer installed
- new mixer runs in panel
Post meeting
* 2 mixers installed
* new mixer runs in panel
* alternate mixer hidden away in the menus
Note that from my outside view we have one glaring problem with our
compromise. We've compromised on what programs go into the images for
F11 but we haven't resolved the fundamental differences of opinion as to
what the user's needs are. Without that this problem will reoccur in
F12, F13, ands o on.
-Toshio
11:24 a.m.
On Saturday 25 April 2009 03:30:09 Toshio Kuratomi wrote:
...
What's really involved in compromise is how far each party moves
from
their original positions from the beginning of the process:
Which, when one side is in a stubborn position, created by their own extreme
desire to dictate what is considered "normal" use, leads to a still-distorted
result which is not "in the middle" but still "dragged to one side a
bit".
The idea here was to *accommodate* the *minority* by providing something
*different* for them because Bastien, Lennart and others are unwilling to cater
for them.
Since they don't want to cater to this minority, what's done to help the
minority should not be putting their [B & L's] noses out of joint.
7:48 p.m.
On Fri, 2009-04-24 at 17:15 -0700, Christopher Aillon wrote:
A compromise works best if both parties are on board. I don't
believe
that the desktop guys will object to the package existing and being
installable if people want. No CLI needed since we have GUI install
tools. The objection is with the mandate for it to be installed by
default on the desktop live/install spins.
*All* parties agreed on the compromise during the meeting, including
those speaking on behalf of the desktop group. Approximate quote (since
I'm on my laptop and don't have the IRC log handy): "I gave you that if
it's what's needed to make this issue go away". Not everyone has to be
100% happy with a compromise (not everyone on the other side of the
fence is 100% happy with it either), it just has to be agreed.
--
Adam Williamson <awilliam(a)redhat.com>
Red Hat
8:26 p.m.
On Fri, 24.04.09 17:48, Adam Williamson (awilliam(a)redhat.com) wrote:
On Fri, 2009-04-24 at 17:15 -0700, Christopher Aillon wrote:
> A compromise works best if both parties are on board. I don't believe
> that the desktop guys will object to the package existing and being
> installable if people want. No CLI needed since we have GUI install
> tools. The objection is with the mandate for it to be installed by
> default on the desktop live/install spins.
*All* parties agreed on the compromise during the meeting, including
those speaking on behalf of the desktop group. Approximate quote (since
I'm on my laptop and don't have the IRC log handy): "I gave you that if
it's what's needed to make this issue go away". Not everyone has to be
100% happy with a compromise (not everyone on the other side of the
fence is 100% happy with it either), it just has to be agreed.
I am not sure if am a considered a 'party' here. This was a decision
of FESCO which I am not part of -- so if I agree or not doesn't matter.
To state this clearly: I did _not_ agree with this 'compromise'. I
think shipping two mixers like this by default is a bad decision, and
I am pretty sure that the big majority of the desktop group is with me
on that.
What I can agree on is that this 'discussion' needs to end. And that's
why I just don't care anymore. I didn't escalate this to FESCO in the
first plce, and I am not fighting this further.
I find it a bit weird that FESCO feels to have to intervene in this
case. Apparently FESCO thinks that making decision on bloody volume
controls is more appropriately done by FESCO than by the desktop
folks. And let me also state that I find it a bit dubious that if a
certain person is not happy with a decision a group of people make in
Fedora he runs to some commitee he himself happens to be member of and
then uses it to push it through regardless what the folks whose area
of expertise the issue belongs to think.
In summary: well done!
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:26 a.m.
On Saturday 25 April 2009 02:26:53 Lennart Poettering wrote:
To state this clearly: I did _not_ agree with this
'compromise'. I
think shipping two mixers like this by default is a bad decision, and
I am pretty sure that the big majority of the desktop group is with me
on that.
In other words, if you think it's not worth supporting people whose needs are
different to yours, you think it's wrong they be supported at all.
Thanks ...
In summary: well done!
Quite.
4:45 p.m.
On Fri, 2009-04-24 at 17:48 -0700, Adam Williamson wrote:
On Fri, 2009-04-24 at 17:15 -0700, Christopher Aillon wrote:
> A compromise works best if both parties are on board. I don't believe
> that the desktop guys will object to the package existing and being
> installable if people want. No CLI needed since we have GUI install
> tools. The objection is with the mandate for it to be installed by
> default on the desktop live/install spins.
*All* parties agreed on the compromise during the meeting, including
those speaking on behalf of the desktop group. Approximate quote (since
I'm on my laptop and don't have the IRC log handy): "I gave you that if
it's what's needed to make this issue go away". Not everyone has to be
100% happy with a compromise (not everyone on the other side of the
fence is 100% happy with it either), it just has to be agreed.
Oh dear.
I never agreed to this compromise. I didn't even know about it until
now.
I *almost* attended the FESCo meeting, so I could make sure my concerns
were represented accurately, but thought better of it for fear of just
fanning the flames further, as I wasn't exactly cooled off at the time.
For my own sanity I needed to get away from this mess and cool off. It
seems I made a grave mistake. My concerns have gotten completely lost,
and apparently were never understood by anyone. Reading the FESCo log is
only making my blood boil hotter.
By the way, Hi, I'm the guy with the "line-in play-through" use case.
I already explained why including gnome-alsamixer does nothing to make
me any happier here so I won't repeat it: (don't worry, it's clean)
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02089.html
My two cents on reverting the VolumeControl feature entirely: Well, I
guess while this would ultimately address my concerns, it is
un-necessarily drastic. It's throwing the baby out with the bath water.
The new gnome-volume-control is a beautiful piece of UI. My only problem
with it is the panel control wasn't doing quite what I wanted. Just the
ability to make one, tiny little change is all I wanted. I want it to
control PCM instead of Master. Since the previous mixer infrastructure
provided UI for making this change, my expectations were that the new
infrastructure would at least continue to provide a hidden option
somewhere for this.
I began my initial thread in an earnest attempt to get some direction as
to how to make this change. I NEVER wanted any visible UI changed. I
never wanted any buttons added. I expected from the *start* to be
messing with some backend settings somewhere, I just needed to know
where they were. After much pain and sorrow, it was revealed there IS a
setting that (supposedly) did what I want. (Though I have not gotten it
to actually work.)
Not everyone has to be
100% happy with a compromise (not everyone on the other side of the
fence is 100% happy with it either), it just has to be agreed.
A compromise that does absolutely nothing, that is 0%, to address my
concerns is productive how?
Have the concerns of the person that sparked this whole thing become
irrelevant at some point along the way?
This thing has certainly spun far out of my control, and no longer even
has much to do with what I wanted in the first place.
4:58 p.m.
On Sat, 2009-04-25 at 16:45 -0500, Callum Lerwick wrote:
A compromise that does absolutely nothing, that is 0%, to address my
concerns is productive how?
Have the concerns of the person that sparked this whole thing become
irrelevant at some point along the way?
This thing has certainly spun far out of my control, and no longer even
has much to do with what I wanted in the first place.
Unfortunately it wasn't just your needs we were trying to address in the
meeting.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:15 p.m.
On Sat, 2009-04-25 at 14:58 -0700, Jesse Keating wrote:
On Sat, 2009-04-25 at 16:45 -0500, Callum Lerwick wrote:
> A compromise that does absolutely nothing, that is 0%, to address my
> concerns is productive how?
>
> Have the concerns of the person that sparked this whole thing become
> irrelevant at some point along the way?
>
> This thing has certainly spun far out of my control, and no longer even
> has much to do with what I wanted in the first place.
Unfortunately it wasn't just your needs we were trying to address in the
meeting.
Just sayin'. I'm sure not getting anything out of this so far.
Who's needs are we trying to address now? Do they have a name? It feels
like FESCo is trying to address the needs of two straw men at this
point.
8:44 p.m.
On 04/26/2009 03:45 AM, Callum Lerwick wrote:
On Sat, 2009-04-25 at 14:58 -0700, Jesse Keating wrote:
> On Sat, 2009-04-25 at 16:45 -0500, Callum Lerwick wrote:
>> A compromise that does absolutely nothing, that is 0%, to address my
>> concerns is productive how?
>>
>> Have the concerns of the person that sparked this whole thing become
>> irrelevant at some point along the way?
>>
>> This thing has certainly spun far out of my control, and no longer even
>> has much to do with what I wanted in the first place.
> Unfortunately it wasn't just your needs we were trying to address in the
> meeting.
Just sayin'. I'm sure not getting anything out of this so far.
Who's needs are we trying to address now? Do they have a name? It feels
like FESCo is trying to address the needs of two straw men at this
point.
They addressed the needs of people like me who want to change the input
sources. I have to change from mic to front mic to record anything at
all or use voice chat and I am not at all twiddle happy in these things.
If it works by default, I wouldn't change a thing. Unfortunately it
doesn't. While I personally can fall back to alsamixer, it is going to
be more trouble for other users.
There is also a smaller number of users for whom, sound does not work at
all until they fiddle with one of the volume control settings in alsamixer.
Fortunately, these are bugs or enhancements requests taken into
consideration by PulseAudio folks and should be fixed by Fedora 12
timeframe.
Rahul
3:38 a.m.
On Sat, 2009-04-25 at 17:15 -0500, Callum Lerwick wrote:
On Sat, 2009-04-25 at 14:58 -0700, Jesse Keating wrote:
> On Sat, 2009-04-25 at 16:45 -0500, Callum Lerwick wrote:
> > A compromise that does absolutely nothing, that is 0%, to address my
> > concerns is productive how?
> >
> > Have the concerns of the person that sparked this whole thing become
> > irrelevant at some point along the way?
Actually I raised the issue with FESCo based on something else, although
your issue and others certainly contributed to my concerns.
My original thought was just that FESCo would gently prod the packagers
who were closing regression bugs as WONTFIX, and encourage them to
behave more responsibly. When it became apparent that gentle
remonstration with the people concerned wasn't going to be sufficient,
something else came out of the discussion instead.
> > This thing has certainly spun far out of my control, and no
longer even
> > has much to do with what I wanted in the first place.
>
> Unfortunately it wasn't just your needs we were trying to address in the
> meeting.
People will always need access to mixer controls. One set of people will
need them because they want to do things that the PulseAudio folks call
"weird", like using that line-in socket on the side of their laptop, or
playing CDs without chewing CPU time doing all those strange unreliable
heuristics we do to knit audio back together when we rip it off a CD. Or
turning their speakers on or off. Or setting the relative levels of bass
and mid-range speakers. Or any number of other things.
Other people need it just to get optimal use out of their hardware in
the "non-weird" cases. Although we're building up a hardware database
which tells us which of those sliders in the alsa-mixer-of-doom actually
do useful things, it can never be completely accurate and up to date.
People will _always_ be able to do better by experimenting for
themselves.
For example, if I want to get the best audible volume out of my laptop,
I may need to tweak the various mixer levels _just_ low enough to avoid
clipping, and the levels required depend on a lot of things -- including
the analogue circuitry in _this_ particular machine, and the ears of the
people present in the room. That information isn't going to be in the
database.
We have to accept that there are _always_ going to be cases where users
want better control over the mixer.
Just sayin'. I'm sure not getting anything out of this so
far.
Callum, I'm sorry we didn't address the panel issue. I wanted to talk
about the panel, but it quickly became clear there wasn't sufficient
consensus on that.
I think it's a fairly poor compromise that we ended up with -- but
that's kind of the point in compromise; it's not really _anyone's_
perfect vision.
On the whole, I _like_ the new F-11 gnome-volume-control -- I just wish
we could just make it work for the cases it currently doesn't handle.
That would be the ideal solution.
(Obviously not just by adding more sliders; it needs to be possible
for users to enable what they _need_ without just showing them the
alsa-mixer-of-doom by default. I'm not really qualified to give a
detailed suggestion on _how_ it's done -- that's a UI decision which I
wish the UI experts would address. I wish they _wouldn't_ try to
address it by simply declaring these uses out of Fedora's scope.
That's a policy decision which I think it's properly within FESCo's
mandate to decide.)
But since there's such resistance to doing that, shipping an alternative
volume control app at least restores functionality to those users who
need it.
It's even more suboptimal that this app is hidden in the menus and not
accessible from the panel. As far as the F-10 user is concerned, this
functionality is just _gone_ from the place it used to be; I'm not sure
they'll think to go looking around in the application menus to find it
again.
But that's the compromise we agreed on. It's far from ideal, but at
least it's only a regression in _usability_ for those users, not a
complete loss of functionality.
To be honest, I think the best option at this stage would really have
been to revert the VolumeControl feature for F-11, and to say "come back
and try again in F-12, and please do a better job next time". But I
definitely don't think we have FESCo consensus on _that_, so I didn't
push it very hard.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
11:32 a.m.
On Sun, 26.04.09 09:38, David Woodhouse (dwmw2(a)infradead.org) wrote:
> > > This thing has certainly spun far out of my control,
and no longer even
> > > has much to do with what I wanted in the first place.
> >
> > Unfortunately it wasn't just your needs we were trying to address in the
> > meeting.
People will always need access to mixer controls. One set of people will
need them because they want to do things that the PulseAudio folks call
"weird", like using that line-in socket on the side of their laptop, or
playing CDs without chewing CPU time doing all those strange unreliable
heuristics we do to knit audio back together when we rip it off a CD. Or
turning their speakers on or off. Or setting the relative levels of bass
and mid-range speakers. Or any number of other things.
Come one. You are misleading people. And you know that.
You say I would call it weird if you wanted to use the line-in
socket. I never said that. Recording from line-in is perfectly valid
and not weird. What I did say however is that using the input feedback
functionality of your sound card as a way to connect two machines to a
single set of speakers is an exotic usage I don't see the need for to
expose in the UI.
And you claim that I'd consider it weird that folks want to "play CDs
without chewing CPU time doing all those strange unreliable heuristics
we do to knit audio back together when we rip it off a CD". This is
misleading too: *none* of the applications which can do CD playback we
install by default even supports the 'analog path' which you are
apparently referring to. And looking further even the ones which are
not installed by default mostly don't do that anymore. I checked
Nautilus, Rhythmbox, Banshee, Sound Juicer. In addition, ripping CDs
for immediate playback is not as problematic anymore as you claim. It
was in the early nineties. But that's over. Also, most modern sound
cards don't even have the CD slider anymore, or even an input to
connect a cable from the CD drive. And modern CD drives don't have
that output for that cable either. Also, if you'd go the 'analog path'
you lose the ability to play from USB cds, to USB speakers, to BT
headphones, to spdif. You lose the ability to have more than one CD to
play from. And so on and so on. CD playing via the 'analog path' is
OBSOLETE! And it would be a PITA to expose in the UI -- about 0.0001%
of the population would even notce the difference and would be able to
tell the system which path to take.
Next thing you claim is that I say it was weird wanting to turn your
speakers on/off. I never said that. What I did say is that it is an
exotic usage to have simultaneous playback of the same stream on your
laptop speakers and on you headphones. Also, your hardware has an
autmatic logic to switch over playback to your headset when you plug
them in. What you asked me for is to expose the ability to override
that logic. That is just exotic. And that's it. Plain
exotic. Switching your speakers on/off is done via the mute checkbox
and that is perfectly well supported.
All three issues you keep repeating here are really really exotic
uses. And you ask us to support them by default. And I closed your
requests as FIXME due to their exoticness, referring you to low-level
mixers which exist plentiful in Fedora. And that's the absolutely
right thing to do.
And let me emphasize the following:
_The fact that you try to mislead people the way you do, shows that you
don't even believe yourself that the points you raise are valid enough
to convince people._
Other people need it just to get optimal use out of their hardware
in
the "non-weird" cases. Although we're building up a hardware database
which tells us which of those sliders in the alsa-mixer-of-doom actually
do useful things, it can never be completely accurate and up to date.
People will _always_ be able to do better by experimenting for
themselves.
Some people will. And they can install a low-level ALSA mixer and go
for it. There is not need to install that by default, clutter the UI
with it.
When will you ever get it: I AM NOT LIMITING IN ANY WAY HOW YOU MAY
USE YOUR SOUND HARDWARE. I AM JUST SAYING IT IS EXOTIC AND DOESN'T
NEED TO BE EXPOSED BY DEFAULT. Is that so hard to understand?
I am not taking your freedom away!
For example, if I want to get the best audible volume out of my
laptop,
I may need to tweak the various mixer levels _just_ low enough to avoid
clipping, and the levels required depend on a lot of things -- including
the analogue circuitry in _this_ particular machine, and the ears of the
people present in the room. That information isn't going to be in the
database.
Actually, ALSA can be very helpful with that since on most hw they
expose dB values which you can be used to set to 0dB for the inner
volume controls.
Thing is that you are asking to have the old g-v-c back WHICH DOESN'T
EVEN SHOW dB VALUES!
What we suggest instead is that the ALSA database sets those sliders
to 0dB by default -- which it does fine for the majority of hardware.
If you'd really care about the quality of your audio you'd allow ALSA
to adjust the levels to 0dB fo you instead of twiddling with those
values yourself.
We have to accept that there are _always_ going to be cases where
users
want better control over the mixer.
Yes, there are always cases where things don't work that well by
default. To fix those cases we have bug trackers or tools to track down
those issues which can be installed on-demand.
(Obviously not just by adding more sliders; it needs to be
possible
for users to enable what they _need_ without just showing them the
alsa-mixer-of-doom by default. I'm not really qualified to give a
detailed suggestion on _how_ it's done -- that's a UI decision which I
wish the UI experts would address. I wish they _wouldn't_ try to
address it by simply declaring these uses out of Fedora's scope.
That's a policy decision which I think it's properly within FESCo's
mandate to decide.)
Ah, thanks. You give us the liberty to do whatever we want as long as
it is exactly what you want. Thanks for that freedom!
It's even more suboptimal that this app is hidden in the menus
and not
accessible from the panel. As far as the F-10 user is concerned, this
functionality is just _gone_ from the place it used to be; I'm not sure
they'll think to go looking around in the application menus to find it
again.
?????
Dude, this is getting more ridiculous with every word you say.
Now you asking that there is a quick-access applet that exposes three
completely exotic things?
a) the ability to connect two machines to a single set of speakers
b) the ability to control the analog path for audio cd playback where
we don't even have a program that could initiate that cd playback
for you
c) the ability to have the same stream on your headphones and your
internal laptop speakers.
You must be kidding me!
To be honest, I think the best option at this stage would really
have
been to revert the VolumeControl feature for F-11, and to say "come back
and try again in F-12, and please do a better job next time". But I
definitely don't think we have FESCo consensus on _that_, so I didn't
push it very hard.
Yes, and I think the best option at this stage would be to finally
agree that the points you raise are bogus. And that FESCO would revert
the decision pushed through by you.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
12:22 p.m.
On Sun, 26.04.09 12:06, Callum Lerwick (seg(a)haxxed.com) wrote:
On Sun, 2009-04-26 at 18:32 +0200, Lennart Poettering wrote:
> _The fact that you try to mislead people the way you do, shows that you
> don't even believe yourself that the points you raise are valid enough
> to convince people._
Lennart is Eric Cartman.
Thanks a lot for this on-topic well-versed technical comment!
This certainly helps to further increase your and fedora-devel's
reputation as being the places to go for good and constructive
technical discussions!
I wished you were more like Kenny.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
1:02 p.m.
Lennart Poettering wrote:
What I did say however is that using the input feedback
functionality of your sound card as a way to connect two machines to a
single set of speakers is an exotic usage I don't see the need for to
expose in the UI.
Funny, I've done that twice (at home, and at work). Doesn't seem at all
unusual for any case of having more than one machine. (I wouldn't even
think it's that unusual even to do things like patching, say, a PS3
through a computer.)
From our perspectives, this usage isn't "exotic" at all, and that you
continually insist it is feels offensive.
I've also seen people doing things like hooking multiple independent
sound systems to single inputs (not computers, granted). IOW, I've seen
more sound setups you consider "exotic" than setups you apparently
consider "mainstream"... *especially* if you take laptops out of the
equation. Now, I don't have a representative sample, but *neither do
you*. Try seeing things from our perspective, for a change, instead of
assuming that you have the truth and we are aberrations.
(Fortunately I am a KDE user, and have kmix, and so this conversation
mostly doesn't apply to me.)
Oh, and, please do not quote my e-mail address unobfuscated in message
bodies. Better yet, please configure your mailer not to do so.
You lose the ability to have more than one CD to play from.
No you don't. I had (and still have, AFAIK) two CDAA cables plugged into
my sound card (one is in AUX), and I believe I have a third AA cable
from a TV tuner. (To be fair, I don't know which, if any, are still
needed, but at any rate, you're wrong that it can't be done.)
--
Matthew
What sort of trite mind
Didst produce this signature
From random input
12:37 p.m.
On Sun, 2009-04-26 at 09:38 +0100, David Woodhouse wrote:
> Just sayin'. I'm sure not getting anything out of this
so far.
Callum, I'm sorry we didn't address the panel issue. I wanted to talk
about the panel, but it quickly became clear there wasn't sufficient
consensus on that.
For the record, [SOLVED]:
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02164.html
Now I can go back to doing something productive. Like play WoW...
1:35 p.m.
On Sun, 2009-04-26 at 09:38 +0100, David Woodhouse wrote:
On Sat, 2009-04-25 at 17:15 -0500, Callum Lerwick wrote:
> Just sayin'. I'm sure not getting anything out of this so far.
Callum, I'm sorry we didn't address the panel issue. I wanted to talk
about the panel, but it quickly became clear there wasn't sufficient
consensus on that.
...And thanks for being the level headed advocate I failed to be. :)
7:45 p.m.
Christopher Aillon wrote:
On 04/24/2009 03:13 PM, Kevin Fenzi wrote:
> == PulseAudio regression handling ==
>
> Long and contentious discussion about concerns with the VolumeControl
> feature. FESCo decided to get gnome-alsamixer packaged and added to the
> default desktop live/install spins to allow users whos use cases are
> not covered currently by VolumeControl to have a GUI way to adjust
> mixer settings. Hopefully this will be dropped/revisited in F12.
Wearing my Board hat, I'll give a quick history lesson: changes were
mandated to codeina a few releases ago post feature freeze. The changes
would have made codeina more acceptable for Fedora's stance on freedom,
however that change was reversed by the board because it was mandated
post feature freeze, and it was agreed future mandates, if any, would
come down pre-feature freeze, but we should not be in the business of
giving mandates.
So I wasn't paying much attention to the codeina bruhaha so please
correct me if I'm wrong in my recollections. My impression was that
FESCo passed on making further changes to the Codeina feature and
*asked* the Board to make a decision because Codeina was a political
issue rather than a technical one. It was also a case where there was
strong feeling by some that codeina violated our principles, the
engineers in charge felt like it didn't, and FESCo, at least by the time
it got to the Board, had decided it wasn't comfortable casting the
deciding ballot.
Are either of those correct? Because in this case we have something
that's a technical issue rather than a political one and FESCo has a
very definite opinion of what the desired outcome should be. They've
also worked with the engineers to come to a compromise solution that
makes no one happy but is tolerable to all. It doesn't require ripping
out, replacing, or modifying the existing feature. The compromise just
adds another package to the install. So to my outside view there's a
lot of difference between this case and codeina.
So, can someone tell me how mandating this is more important than
mandating Fedora be free,
If there's a question of whether something is free and FESCo doesn't
think it's cut and dry what the answer is, it becomes a Board decision
whether the problem falls on the not-for-Fedora side of non-free or the
ok-with-reservations side. (Even if it's not cut and dry, it may be a
Board decision but packagers and FESCo have handled the "easy" cases on
their own to the benefit of all.... You wouldn't want license questions
to have to go through the Board when spot and the Packaging Committee
with FESCo for arbitration is usually enough.)
So the answer to your question is it's not more important than Fedora
being Free but rather, different than that decision.
and why this decree should not be reversed?
In today's voting, FESCo as a whole refused to micromanage the desktop
SIG into changing existing UI. This isn't because they changed their
minds about the ideal state of mixers in Fedora 11 but because they saw
that when you disagree with people that you delegate power to you have
to work with the other party to accommodate both your interests and theirs.
If the Board wants to reverse the decision of what goes onto a spin by
default they can because they are the source of FESCo's authority on
technical matters. But that means that they're taking away all of the
authority that they've given FESCo for technical matters with no
compromise which is a very different thing than what occurred between
FESCo and the Desktop SIG at today's meeting.
Do I really need to bring this up at the next board meeting?
That's a very strange question as only you know what you have to do. If
you are asking whether FESCo wants you to do so I'm afraid I'm not on
FESCo so I can't answer.
-Toshio
12:24 p.m.
On Fri, Apr 24, 2009 at 05:45:01PM -0700, Toshio Kuratomi wrote:
Christopher Aillon wrote:
> and why this decree should not be reversed?
In today's voting, FESCo as a whole refused to micromanage the desktop
SIG into changing existing UI. This isn't because they changed their
minds about the ideal state of mixers in Fedora 11 but because they saw
that when you disagree with people that you delegate power to you have
to work with the other party to accommodate both your interests and theirs.
If the Board wants to reverse the decision of what goes onto a spin by
default they can because they are the source of FESCo's authority on
technical matters. But that means that they're taking away all of the
authority that they've given FESCo for technical matters with no
compromise which is a very different thing than what occurred between
FESCo and the Desktop SIG at today's meeting.
I guess I'm unclear on why the gnome-alsamixer isn't being introduced
as a specific addition to %packages in the DVD kickstart file. Then
the Desktop Live image would retain the characteristics designed by
the Desktop SIG.
That Live image is designed, AIUI, to go into the hands of a novice
who's looking for the Desktop SIG's idea of a Fedora Desktop. On the
other hand, anyone who's looking for twiddly bits like those found in
the gnome-alsamixer (and they're perfectly justified in that desire)
are typically going to download the Installation DVD because they want
more choices in software to begin with.
So to me, the ideal compromise is for the Installation DVD to install
the gnome-alsamixer by default and have it in the menu, and for the
Desktop Live image not to bother. Does that not solve the problem in
a less contentious way?
> Do I really need to bring this up at the next board meeting?
>
That's a very strange question as only you know what you have to do. If
you are asking whether FESCo wants you to do so I'm afraid I'm not on
FESCo so I can't answer.
To be very clear, the above is just my input as a long-time Fedora
contributor. But if this escalates to the Board, in all honesty it
would still be my position.
I think FESCo is doing the right thing by including something that
will work for the large number of users we have who are natural
bit-twiddlers, and require functionality beyond what the
drivers/hardware currently make available to PA. But I also think the
Desktop SIG ought to be able to make a Desktop Spin that represents
their vision. In fact, that's something we've asked for at, e.g., the
recent FUDCon in Boston last January.
So again, I propose adding gnome-alsamixer to the %packages in
Installation DVD kickstart, and leave the Desktop Live CD as-is.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
12:37 p.m.
On Sat, 2009-04-25 at 13:24 -0400, Paul W. Frields wrote:
I guess I'm unclear on why the gnome-alsamixer isn't being
introduced
as a specific addition to %packages in the DVD kickstart file. Then
the Desktop Live image would retain the characteristics designed by
the Desktop SIG.
That Live image is designed, AIUI, to go into the hands of a novice
who's looking for the Desktop SIG's idea of a Fedora Desktop. On the
other hand, anyone who's looking for twiddly bits like those found in
the gnome-alsamixer (and they're perfectly justified in that desire)
are typically going to download the Installation DVD because they want
more choices in software to begin with.
So to me, the ideal compromise is for the Installation DVD to install
the gnome-alsamixer by default and have it in the menu, and for the
Desktop Live image not to bother. Does that not solve the problem in
a less contentious way?
I think FESCo is doing the right thing by including something that
will work for the large number of users we have who are natural
bit-twiddlers, and require functionality beyond what the
drivers/hardware currently make available to PA. But I also think the
Desktop SIG ought to be able to make a Desktop Spin that represents
their vision. In fact, that's something we've asked for at, e.g., the
recent FUDCon in Boston last January.
So again, I propose adding gnome-alsamixer to the %packages in
Installation DVD kickstart, and leave the Desktop Live CD as-is.
I'd be against this just because the problematic use case is so basic.
This is not for 'natural bit-twiddlers', it's for just about anyone who
wants to take any kind of sound from an external source. This is
something regular users do all the time. I know this, I spend time in
forums. People want to record old records or audio tapes or from the
radio to file, they want to use VOIP, there's a zillion uses for this.
"I want input from Mic 2 instead of Mic 1" or "I want input from line-in
instead of Mic 1" is not a bit-twiddling use case, it's an amazingly
basic function that many many people expect to work.
Windows isn't any kind of guide to good UI, but it's worth noting what
Windows does, just because it's what people expect: Windows has a
notification tray applet which just gives you a simple slider (a la the
new g-v-c), but from the right-click menu, you can launch the Windows
'advanced' mixer with access to all the mixer elements (a la this
proposal). Again, I'm not saying 'because Windows does it it's the best
way to do things and we should do it too', that's clearly nuts, but I
have personally seen dozens of people - not 'bit twiddlers', just
regular people with regular needs - use this application. I think you're
maybe just underestimating the level of need for this.
In the initial bug report related to this discussion I've pointed up a
forum thread where several people thanked me for the alsamixer -c0
trick. That's just people running F11 beta who happened to find that
forum thread. Multiply that out to everyone who tries F11 final...
and the problem came up at least five separate times across this list
and fedora-test-list too. There are clearly many many people who *need*
access to this functionality. It's not just bit-twiddlers.
--
Adam Williamson <awilliam(a)redhat.com>
Red Hat
7:18 p.m.
On Sat, 25 Apr 2009 10:37:57 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
On Sat, 2009-04-25 at 13:24 -0400, Paul W. Frields wrote:
...snip...
> So again, I propose adding gnome-alsamixer to the %packages in
> Installation DVD kickstart, and leave the Desktop Live CD as-is.
...snip...
and the problem came up at least five separate times across this
list
and fedora-test-list too. There are clearly many many people who
*need* access to this functionality. It's not just bit-twiddlers.
I would like to add that I have seen this in #fedora a good deal as
well of late. Our pulseaudio fixes page is consistently in the top 5
links used every week on the channel.
I would hope that having something in the menus to work around this
would reduce support burden, and end use frustration.
Also, we often tell folks to try out the live cd, the live cd is what
is given away at events, etc. So I think this is something that many
people will use/see on first install.
kevin
12:27 a.m.
Paul W. Frields wrote:
I think FESCo is doing the right thing by including something that
will work for the large number of users we have who are natural
bit-twiddlers, and require functionality beyond what the
drivers/hardware currently make available to PA. But I also think the
Desktop SIG ought to be able to make a Desktop Spin that represents
their vision. In fact, that's something we've asked for at, e.g., the
recent FUDCon in Boston last January.
Something that jwb noticed in the FESCo meeting but didn't get explored
is that many FESCo members referred to the live spin as the "default
spin" whereas the desktop team members referred to it as the "desktop
spin". I think this is an important thing to ponder. FESCo has been
pushing the distribution away from the install DVD and more towards the
live images. I think this is a good thing as it gives new (and old...
I'm going to be trying a few spins on USB before upgrading the rest of
my computers to F11) users the ability to try things out before they
settle on what they want.
However, this means that the public face of the Fedora Distribution is
not whatever the user gets after they customize the package set from the
install DVD and install those packages onto the hard drive. It means
that the user's impression of what Fedora is is largely what they get
when they boot the "default spin" that's the first entry here:
http://fedoraproject.org/get-fedora
With this in mind, we currently have a desktop spin but it's not the
exclusive playground of the desktop team. The spin is also tied very
tightly to what Fedora the Distribution is. And that's why FESCo feels
the need to have a say in what's on that particular spin when it seems
to not be providing what users want.
Is this a mistake? The desktop team gets exposure for their work by
being the default spin but they also have to contend with more
stake-holders in the results of their work. mclasen brought up the
empathy issue from last release and I'm pretty sure the mono-banshee
feature that was pushed at the desktop team this release was directed at
getting it onto the default spin rather than what the desktop team
produces specifically.
Now I'm not on FESCo and I'm not on the desktop team, so what do the
real stakeholders here think? Desktop team, do you get enough value
from being the default spin to outweigh the extra burden of satisfying
everyone who thinks of the Desktop Spin as the Fedora Distribution?
FESCo, if the desktop team says they want a spin of their own to
control, are you willing to figure out a different spin (or different
method) for telling user's what the Fedora Distribution is?
-Toshio
11:02 a.m.
On Sat, 2009-04-25 at 22:27 -0700, Toshio Kuratomi wrote:
Now I'm not on FESCo and I'm not on the desktop team, so what
do the
real stakeholders here think? Desktop team, do you get enough value
from being the default spin to outweigh the extra burden of satisfying
everyone who thinks of the Desktop Spin as the Fedora Distribution?
FESCo, if the desktop team says they want a spin of their own to
control, are you willing to figure out a different spin (or different
method) for telling user's what the Fedora Distribution is?
The fundamental problem is that nobody knows what Fedora is. It gets
constantly torn into different directions, and as a result, makes nobody
happy. See recent board agendas ("What is Fedora")...
12:07 p.m.
Matthias Clasen wrote:
On Sat, 2009-04-25 at 22:27 -0700, Toshio Kuratomi wrote:
> Now I'm not on FESCo and I'm not on the desktop team, so what do the
> real stakeholders here think? Desktop team, do you get enough value
> from being the default spin to outweigh the extra burden of satisfying
> everyone who thinks of the Desktop Spin as the Fedora Distribution?
> FESCo, if the desktop team says they want a spin of their own to
> control, are you willing to figure out a different spin (or different
> method) for telling user's what the Fedora Distribution is?
The fundamental problem is that nobody knows what Fedora is. It gets
constantly torn into different directions, and as a result, makes nobody
happy. See recent board agendas ("What is Fedora")...
I think this is a bit of a distraction. The Board is discussing what
Fedora the Project is. Fedora the Distribution is very concretely
specified by what's on the get-fedora page.
Now, what Fedora the Project is does affect what Fedora the Distribution
is but not in the same way as the concrete package set that gets run on
your computer. The Board could say "Fedora is a project that aims at
making computers as easy to use as possible" and we'd still be having
this discussion about which packages on the default spin fulfill that
vision.
-Toshio
12:10 p.m.
On Sun, Apr 26, 2009 at 12:02:31PM -0400, Matthias Clasen wrote:
On Sat, 2009-04-25 at 22:27 -0700, Toshio Kuratomi wrote:
> Now I'm not on FESCo and I'm not on the desktop team, so what do the
> real stakeholders here think? Desktop team, do you get enough value
> from being the default spin to outweigh the extra burden of satisfying
> everyone who thinks of the Desktop Spin as the Fedora Distribution?
> FESCo, if the desktop team says they want a spin of their own to
> control, are you willing to figure out a different spin (or different
> method) for telling user's what the Fedora Distribution is?
The fundamental problem is that nobody knows what Fedora is. It gets
constantly torn into different directions, and as a result, makes nobody
happy. See recent board agendas ("What is Fedora")...
While I disagree with the conclusion you made, I do agree that nobody has a
clear definition of what Fedora as an _OS_ is. What the Board is addressing
is slightly different, as it is tackling what Fedora is from a project view.
FESCo should be taking that overall direction from the Board and making sure
the technical composition of the default Fedora distro release puts forth the
best approximation of those higher level goals.
That is not to say that other spins are of lesser value. But you make a good
point in that the current spins situation is a bit confusing for end-users.
josh
7:24 p.m.
On Sat, 25 Apr 2009 22:27:29 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
...snip...
FESCo, if the desktop team says they want a spin of their own to
control, are you willing to figure out a different spin (or different
method) for telling user's what the Fedora Distribution is?
I can't answer for FESCo, but I think this could be very hard to do.
We could have a 'default' and a 'desktop' spins, but would the amount
of changes between them justify confusing our users more?
Would this default use Gnome? If so, how different would it be from the
desktop spin?
I personally wouldn't object to making it more clear that there were
various spin choices, but the difficulty is how to present them
clearly.
-Toshio
kevin
5:13 a.m.
Toshio Kuratomi wrote:
If the Board wants to reverse the decision of what goes onto a spin
by
default they can because they are the source of FESCo's authority on
technical matters. But that means that they're taking away all of the
authority that they've given FESCo for technical matters with no
compromise which is a very different thing than what occurred between
FESCo and the Desktop SIG at today's meeting.
I must say that, while I do believe users need to have access to the sound
card controls exposed by ALSA, the precedent this decision sets worries me.
It should ultimately be the GNOME Desktop Team's decision to decide what
goes onto the GNOME spin. I definitely wouldn't be happy if FESCo started
dictating the contents of the KDE spin.
Kevin Kofler
10:23 a.m.
On Sun, 2009-04-26 at 12:13 +0200, Kevin Kofler wrote:
I must say that, while I do believe users need to have access to the
sound
card controls exposed by ALSA, the precedent this decision sets worries me.
It should ultimately be the GNOME Desktop Team's decision to decide what
goes onto the GNOME spin. I definitely wouldn't be happy if FESCo started
dictating the contents of the KDE spin.
I don't see it as dictation. I see it as reaching a compromise. FESCo
didn't even vote on it until after mclasen agreed to put the mixer
there.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:28 a.m.
On Sun, 26.04.09 08:23, Jesse Keating (jkeating(a)redhat.com) wrote:
On Sun, 2009-04-26 at 12:13 +0200, Kevin Kofler wrote:
> I must say that, while I do believe users need to have access to the sound
> card controls exposed by ALSA, the precedent this decision sets worries me.
> It should ultimately be the GNOME Desktop Team's decision to decide what
> goes onto the GNOME spin. I definitely wouldn't be happy if FESCo started
> dictating the contents of the KDE spin.
I don't see it as dictation. I see it as reaching a compromise. FESCo
didn't even vote on it until after mclasen agreed to put the mixer
there.
Uh. I wouldn't call this a compromise. One side just had enough of this
pita and retreated not caring anymore.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:10 a.m.
On Sun, 2009-04-26 at 08:23 -0700, Jesse Keating wrote:
On Sun, 2009-04-26 at 12:13 +0200, Kevin Kofler wrote:
> I must say that, while I do believe users need to have access to the sound
> card controls exposed by ALSA, the precedent this decision sets worries me.
> It should ultimately be the GNOME Desktop Team's decision to decide what
> goes onto the GNOME spin. I definitely wouldn't be happy if FESCo started
> dictating the contents of the KDE spin.
I don't see it as dictation. I see it as reaching a compromise. FESCo
didn't even vote on it until after mclasen agreed to put the mixer
there.
Of course, having wwoods threaten to revert the whole VolumeControl
feature has nothing to do with it...
12:50 p.m.
On Sun, 2009-04-26 at 12:10 -0400, Matthias Clasen wrote:
On Sun, 2009-04-26 at 08:23 -0700, Jesse Keating wrote:
> On Sun, 2009-04-26 at 12:13 +0200, Kevin Kofler wrote:
> > I must say that, while I do believe users need to have access to the sound
> > card controls exposed by ALSA, the precedent this decision sets worries me.
> > It should ultimately be the GNOME Desktop Team's decision to decide what
> > goes onto the GNOME spin. I definitely wouldn't be happy if FESCo started
> > dictating the contents of the KDE spin.
>
> I don't see it as dictation. I see it as reaching a compromise. FESCo
> didn't even vote on it until after mclasen agreed to put the mixer
> there.
Of course, having wwoods threaten to revert the whole VolumeControl
feature has nothing to do with it...
Given that wwoods isn't even in FESCo, that'd be a neat trick. But
isn't that the very definition of compromise? Two sides each have
desires that neither side can agree upon. Each side makes concessions
until they meet somewhere in the middle?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:50 p.m.
Hi Jesse,
On Wed, Apr 29, 2009 at 1:50 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Sun, 2009-04-26 at 12:10 -0400, Matthias Clasen wrote:
> On Sun, 2009-04-26 at 08:23 -0700, Jesse Keating wrote:
> > On Sun, 2009-04-26 at 12:13 +0200, Kevin Kofler wrote:
> > > I must say that, while I do believe users need to have access to the sound
> > > card controls exposed by ALSA, the precedent this decision sets worries
me.
> > > It should ultimately be the GNOME Desktop Team's decision to decide
what
> > > goes onto the GNOME spin. I definitely wouldn't be happy if FESCo
started
> > > dictating the contents of the KDE spin.
> >
> > I don't see it as dictation. I see it as reaching a compromise. FESCo
> > didn't even vote on it until after mclasen agreed to put the mixer
> > there.
>
> Of course, having wwoods threaten to revert the whole VolumeControl
> feature has nothing to do with it...
Given that wwoods isn't even in FESCo, that'd be a neat trick. But
isn't that the very definition of compromise? Two sides each have
desires that neither side can agree upon. Each side makes concessions
until they meet somewhere in the middle?
OK, so here's the problem with this. Compromise sometimes works well
when trying to form rough consensus, or for finding the least
disagreeable position for the most people - for politics maybe.
However, it does not work well as a technique for designing products
that people love to use. When you find the middle ground between
great and awful you don't find good - you find mediocrity and malaise.
Please read http://headrush.typepad.com/ for more on this topic.
We've been designing compromised products for far too long. We need
to acknowledge that we can't please everyone all the time and need to
make choices. We need to resolve to be great - it doesn't just happen
by accident.
Another thing we have here is a classical case of design by committee.
This "compromise" dictated by FESCO is a design decision. A decision
that affects the look, feel, behavior, and experience of the desktop.
Firstly, we should be very sceptical that *any* committee can make
great design decisions (see
http://www.codinghorror.com/blog/archives/000321.html). Secondly,
this particular committee is simply not qualified to make design
decisions for the desktop - you are all well meaning and very good at
your particular field but frankly not the people that should be
designing our experiences.
In this particular case, there is nothing wrong with telling some
people either: a) you may have to wait for the next release in order
to get the optimal experience or b) go to this wiki page and follow
the instructions to make it work on your somewhat atypical
system/setup. We simply cannot avoid this if we continue to use a
time-based release process. There will always be cases where we don't
finish everything we'd like to. The answer cannot be - let's
compromise our vision and create crappy products. That is, it cannot
if we ever want to recover marketshare and mindshare from other
distributions (not to mention other/better OS's), and make something
kick-ass that we can be proud of. The only other option is to move to
a feature and/or goal based release process where you release when
things are done. However, I'm not sure this is the right thing to do
at this time.
I know you work really hard and care a lot about Fedora, and I'm
picking on you a bit because we all respect you, but honestly the
opinion you expressed is part of what is wrong with Fedora today. We
have a lot of work to do to make Fedora truly great - and one of the
first and most important things is to make sure we have the mindset
that will allow us to achieve greatness.
Thanks,
Jon
1:29 p.m.
On Thu, 2009-04-30 at 13:50 -0400, William Jon McCann wrote:
OK, so here's the problem with this. Compromise sometimes works
well
when trying to form rough consensus, or for finding the least
disagreeable position for the most people - for politics maybe.
However, it does not work well as a technique for designing products
that people love to use. When you find the middle ground between
great and awful you don't find good - you find mediocrity and malaise.
Please read http://headrush.typepad.com/ for more on this topic.
We've been designing compromised products for far too long. We need
to acknowledge that we can't please everyone all the time and need to
make choices. We need to resolve to be great - it doesn't just happen
by accident.
Sorry, but I think you're picking entirely the wrong case to try and
make your point. Try as hard as I can, I can't see how it would be
better to have the Brave New World mixer and a wiki page instructing
people on how to use alsamixer than it is to have the Brave New World
mixer and a second mixer application available in the menus. The total
cost to the design of the desktop is: one additional menu entry. I'm
really having a hard time seeing how this is a terrible design decision.
(and later in the post you repeat the "somewhat atypical system/setup"
canard. "I want to select an input channel" is not remotely atypical.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:35 p.m.
Adam Williamson (awilliam(a)redhat.com) said:
"I want to select an input channel" is not remotely
atypical.
But then, the solution (in a time-based release system) is to decide
at the appropriate point that the new code does not hit the required
feature matrix yet, and shelve the new code until the next release
where it meets the required feature matrix. (See: Empathy).
Where the issue arises here is that we've passed that appropriate point
in the schedule; since we can't push to the next release now, nor do we
have time to do anything new sanely, I'm not convinced that anything we
do/add now will be sufficiently better than doing nothing at all.
Bill
1:41 p.m.
On Thu, 2009-04-30 at 14:35 -0400, Bill Nottingham wrote:
Adam Williamson (awilliam(a)redhat.com) said:
> "I want to select an input channel" is not remotely atypical.
But then, the solution (in a time-based release system) is to decide
at the appropriate point that the new code does not hit the required
feature matrix yet, and shelve the new code until the next release
where it meets the required feature matrix. (See: Empathy).
Where the issue arises here is that we've passed that appropriate point
in the schedule; since we can't push to the next release now, nor do we
have time to do anything new sanely, I'm not convinced that anything we
do/add now will be sufficiently better than doing nothing at all.
I think adding an alternative mixer application which doesn't interfere
with the new one in any way (and doesn't break anything significant even
if it somehow fails to work entirely) is a pretty safe and conservative
choice, and that's why FESco agreed to do so. It also confers a
significant benefit, i.e. a way to adjust what needs to be adjusted
without having to use an obscure console application which few people
know how to use or are even aware exists. I mean, look, come on, just
look at it from a pragmatic viewpoint: it's a single package containing
code we've already shipped for multiple releases, which we *know* works.
Heck, it's code Ubuntu 9.04 is shipping as its default mixer
application. What, as slashdot would put it, couldpossiblygowrong?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:12 p.m.
On Thu, 30 Apr 2009 14:35:35 -0400
Bill Nottingham <notting(a)redhat.com> wrote:
Adam Williamson (awilliam(a)redhat.com) said:
> "I want to select an input channel" is not remotely atypical.
But then, the solution (in a time-based release system) is to decide
at the appropriate point that the new code does not hit the required
feature matrix yet, and shelve the new code until the next release
where it meets the required feature matrix. (See: Empathy).
Agreed. Unfortunately, sometimes it's hard to assess that, particularly
for desktop features that don't get more widespread testing until very
late in the cycle. (See: we need more people using rawhide day to day
as their main machines).
Where the issue arises here is that we've passed that
appropriate
point in the schedule; since we can't push to the next release now,
nor do we have time to do anything new sanely, I'm not convinced that
anything we do/add now will be sufficiently better than doing nothing
at all.
I think offering a gui mixer applet menu item for those folks that (for
various reasons) sound doesn't work out of the box for is still worth
while. (Although I agree time is running out...)
I agree that the Gnome folks should be able to setup their desktop
however they feel is best. It's their product. However, I also think
that because it's the desktop that people will see by default and is
very heavily associated with what people think of when they think
"fedora", the Fedora project should have input sometimes in how it's
integrated.
I have 2 selfish reasons for wanting a gui mixer to be shipped with
F11:
1. I like Fedora. I want it to be well spoken of and enjoyed by anyone
who tries it out. I think that doing this will reduce the amount of
people who are unhappy/mad/displeased with the Fedora I love.
I think that for those people who the volume works for won't even
notice it's there.
2. I help out on various fedora support channels. #fedora on irc,
fedora-list and I have even been poking around on fedoraforum.
I think without this the support burden would be increased on all of
these channels. The way I see it:
a Most people - everything works, sounds good.
b Some people - sound does not work for, they give up and go to another
distro or post angry messages and go somewhere else.
c Some people - sound does not work, they look around the menus and
find a mixer. Tweak it and get it working.
d Some people - Go to support channels in various states of upset and
get told to use 'alsamixer -c0' in a terminal, or xfce4-mixer or
something else and get it to work.
I think adding c there decreases the number of people who get to d.
Hopefully in the next cycle those cases can be identified and we will
no longer need c in there. I don't see how adding step c really affects
anything but some users for whom sound isn't ideal.
Bill
kevin
2:08 p.m.
Hi,
On Thu, Apr 30, 2009 at 2:29 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2009-04-30 at 13:50 -0400, William Jon McCann wrote:
> OK, so here's the problem with this. Compromise sometimes works well
> when trying to form rough consensus, or for finding the least
> disagreeable position for the most people - for politics maybe.
> However, it does not work well as a technique for designing products
> that people love to use. When you find the middle ground between
> great and awful you don't find good - you find mediocrity and malaise.
> Please read http://headrush.typepad.com/ for more on this topic.
>
> We've been designing compromised products for far too long. We need
> to acknowledge that we can't please everyone all the time and need to
> make choices. We need to resolve to be great - it doesn't just happen
> by accident.
Sorry, but I think you're picking entirely the wrong case to try and
make your point. Try as hard as I can, I can't see how it would be
better to have the Brave New World mixer and a wiki page instructing
people on how to use alsamixer than it is to have the Brave New World
mixer and a second mixer application available in the menus. The total
cost to the design of the desktop is: one additional menu entry. I'm
really having a hard time seeing how this is a terrible design decision.
Look, calling our design the "Brave New World mixer" doesn't
particularly make you come across as someone we should be listening
to. And frankly, if you can't see why it is dumb to have two entries
in the menu for controlling your sound and volume then well maybe we
shouldn't be listening to you. Also, seems like a bad decision to
want to QA two entirely separate code paths for doing essentially the
same thing.
Jon
2:33 p.m.
On 04/30/2009 03:08 PM, William Jon McCann wrote:
Look, calling our design the "Brave New World mixer"
doesn't
particularly make you come across as someone we should be listening
to. And frankly, if you can't see why it is dumb to have two entries
in the menu for controlling your sound and volume then well maybe we
shouldn't be listening to you.
Remember kids, we probably shouldn't be listening to you. Red Hat
Desktop == Smart. You == Dumb.
~spot
2:38 p.m.
On Thu, 30 Apr 2009, Tom \"spot\" Callaway wrote:
On 04/30/2009 03:08 PM, William Jon McCann wrote:
> Look, calling our design the "Brave New World mixer" doesn't
> particularly make you come across as someone we should be listening
> to. And frankly, if you can't see why it is dumb to have two entries
> in the menu for controlling your sound and volume then well maybe we
> shouldn't be listening to you.
Remember kids, we probably shouldn't be listening to you. Red Hat
Desktop == Smart. You == Dumb.
I mean - look at how much money red hat has made off of the desktop.....
hey... wait a second!
-sv
2:48 p.m.
Tom spot Callaway (tcallawa(a)redhat.com) said:
On 04/30/2009 03:08 PM, William Jon McCann wrote:
> Look, calling our design the "Brave New World mixer" doesn't
> particularly make you come across as someone we should be listening
> to. And frankly, if you can't see why it is dumb to have two entries
> in the menu for controlling your sound and volume then well maybe we
> shouldn't be listening to you.
Remember kids, we probably shouldn't be listening to you. Red Hat
Desktop == Smart. You == Dumb.
Wheee, double-sided pointless antagonism! Ah, the joys of fedora-devel
in its most common, mostly-useless form.
In any case, it *is* a fairly obvious point in user interface design
that giving users two identical choices that pop-up/run entirely different
things is a horrible UI. It confuses the new user, makes writing coherent
docs a mess, etc. I didn't really know that this was a debatable point.
Of course, I don't know that the proposed solution does this, since,
a week after it was proposed, a week after we've cut our last milestone
release, and less than two weeks before we cut the hopefully-to-be-shipped
release candidate, this proposed solution *has yet to land in any form
at all*. Given the stage of the schedule now, I find it pretty preposterous
that we're still considering changing things.
Bill
3:01 p.m.
On 04/30/2009 07:48 PM, Bill Nottingham wrote:
<snip>
....
</snip>
Of course, I don't know that the proposed solution does this,
since,
a week after it was proposed, a week after we've cut our last milestone
release, and less than two weeks before we cut the hopefully-to-be-shipped
release candidate, this proposed solution *has yet to land in any form
at all*. Given the stage of the schedule now, I find it pretty preposterous
that we're still considering changing things
Agreed.
With Empathy we noticed things early in the release cycle
and thus could revert those changes in time and thus reefer those wanting
to use Empathy to install it manually.
With PAVC things got notice to late in the release cycle and thus those
that need
any functionality that PAVC does not provide should be refereed to
install the old application
manually and ask/or participate early in the release cycle to prevent
these kind
of situation from happening again.
I also think it should be considered a good working rule not to replace
application with a another application until that application provides
equal or better
functionality than the previous one.
Just my 2cents.
JBG
3:13 p.m.
On Thu, Apr 30, 2009 at 08:01:33PM +0000, "Jóhann B. Guðmundsson" wrote:
On 04/30/2009 07:48 PM, Bill Nottingham wrote:
I also think it should be considered a good working rule not to replace
application with a another application until that application provides
equal or better
functionality than the previous one.
That is the crux of the whole argument though. Side A says PVAC doesn't
provide equal or better functionality, Side B says that "functionality"
is weird-case and out of scope.
So it depends on who is doing the determination of 'equal or better'.
Which, apparently, can produce different results.
josh
3:59 p.m.
On Thu, 2009-04-30 at 20:01 +0000, "Jóhann B. Guðmundsson" wrote:
> Of course, I don't know that the proposed solution does
this, since,
> a week after it was proposed, a week after we've cut our last milestone
> release, and less than two weeks before we cut the hopefully-to-be-shipped
> release candidate, this proposed solution *has yet to land in any form
> at all*. Given the stage of the schedule now, I find it pretty preposterous
> that we're still considering changing things
Agreed.
With Empathy we noticed things early in the release cycle
and thus could revert those changes in time and thus reefer those wanting
to use Empathy to install it manually.
This kind of argument just doesn't reflect reality. If it were actually
true, it would be valid. If it were true that we change almost nothing
after a preview release, the point would be significant.
But it's just not true. Did you see the rawhide compose message for
today? It contains three new packages and changes to 50, including basic
components of GNOME and KDE. Tuesday's rawhide featured nine changes to
the *kernel*.
You can't move the goalposts about. If the rule is changing things after
preview is a really significant deal, then there shouldn't be that level
of changes actually happening.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:12 p.m.
On 04/30/2009 08:59 PM, Adam Williamson wrote:
<snip>
....
</snip>
On Thu, 2009-04-30 at 20:01 +0000, "Jóhann B. Guðmundsson"
wrote:
You can't move the goalposts about. If the rule is changing things after
preview is a really significant deal, then there shouldn't be that level
of changes actually happening.
Hum...
Afaik I know the final freeze was "Tue 2009-04-14"
This meeting was held 10 day's later..
And as is mentioned in final freeze policy
" The purpose of the final freeze is to prevent changes while the
release is prepared"
I would categories this as an significant change.
"As of the final freeze for a release, no new builds are allowed for
packages already in the Fedora collection
(new packages can still be reviewed, added in CVS and built as potential
updates)"
And I would think that the other application would have to follow the
above procedure and be built as potential update.
I must be misunderstanding something which is not the first time nor the
last :(
JBG
http://poelstra.fedorapeople.org/schedules/f-11/
https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy
5:55 p.m.
On Thu, 2009-04-30 at 22:12 +0000, "Jóhann B. Guðmundsson" wrote:
On 04/30/2009 08:59 PM, Adam Williamson wrote:
<snip>
....
</snip>
> On Thu, 2009-04-30 at 20:01 +0000, "Jóhann B. Guðmundsson" wrote:
>
>
> You can't move the goalposts about. If the rule is changing things after
> preview is a really significant deal, then there shouldn't be that level
> of changes actually happening.
>
Hum...
Afaik I know the final freeze was "Tue 2009-04-14"
This meeting was held 10 day's later..
And as is mentioned in final freeze policy
" The purpose of the final freeze is to prevent changes while the
release is prepared"
I would categories this as an significant change.
"As of the final freeze for a release, no new builds are allowed for
packages already in the Fedora collection
(new packages can still be reviewed, added in CVS and built as potential
updates)"
And I would think that the other application would have to follow the
above procedure and be built as potential update.
I must be misunderstanding something which is not the first time nor the
last :(
Well, as I said, just look at what actually happens. The policy is
clearly not honored. Look back at the rawhide compose reports since
2009-04-14, and see the changes yourself.
It's a bit hard to cite this policy as an objection to just *one*
change, while hundreds of other fly by unchallenged.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:09 p.m.
On Thu, 2009-04-30 at 15:55 -0700, Adam Williamson wrote:
It's a bit hard to cite this policy as an objection to just *one*
change, while hundreds of other fly by unchallenged.
The other changes are exceptions to the freeze rule, which have to go
through an approval process and get approved by at least 2 releng
members.
The real point of the freeze is to prevent unwanted change from getting
in, accidental or otherwise.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:25 a.m.
"Jóhann B. Guðmundsson" wrote:
"As of the final freeze for a release, no new builds are allowed
for
packages already in the Fedora collection
(new packages can still be reviewed, added in CVS and built as potential
updates)"
And I would think that the other application would have to follow the
above procedure and be built as potential update.
I must be misunderstanding something which is not the first time nor the
last :(
The new packages are actually getting inherited from F10 updates. This needs
to be fixed somehow. (We should probably create separate f*-final tags
early again.)
Kevin Kofler
12:17 p.m.
On Sat, May 02, 2009 at 06:25:19PM +0200, Kevin Kofler wrote:
"Jóhann B. Guðmundsson" wrote:
> "As of the final freeze for a release, no new builds are allowed for
> packages already in the Fedora collection
> (new packages can still be reviewed, added in CVS and built as potential
> updates)"
>
> And I would think that the other application would have to follow the
> above procedure and be built as potential update.
>
> I must be misunderstanding something which is not the first time nor the
> last :(
The new packages are actually getting inherited from F10 updates. This needs
to be fixed somehow. (We should probably create separate f*-final tags
early again.)
It has been fixed.
josh
3:34 p.m.
On Thu, 2009-04-30 at 15:48 -0400, Bill Nottingham wrote:
Wheee, double-sided pointless antagonism! Ah, the joys of
fedora-devel
in its most common, mostly-useless form.
In any case, it *is* a fairly obvious point in user interface design
that giving users two identical choices that pop-up/run entirely different
things is a horrible UI. It confuses the new user, makes writing coherent
docs a mess, etc. I didn't really know that this was a debatable point.
I never said it was good. I said it was less bad than EXPECTING PEOPLE
TO TELEPATHICALLY DISCOVER THE EXISTENCE OF alsamixer.
What is the goal of good UI design? Happy users. Is a user who can't
hear any sound and doesn't know how the hell to fix it happy? No. Is
'good UI design that results in a non-functional system and a pissed-off
user' better than 'bad UI design that results in a functioning system
and a happier user'? No. You can't see the wood for the trees.
Of course, I don't know that the proposed solution does this,
since,
a week after it was proposed, a week after we've cut our last milestone
release, and less than two weeks before we cut the hopefully-to-be-shipped
release candidate, this proposed solution *has yet to land in any form
at all*. Given the stage of the schedule now, I find it pretty preposterous
that we're still considering changing things.
I had gnome-alsamixer packaged and ready to go on Monday; it would have
been faster if things hadn't happened over a weekend where I was at a
conference. That's https://bugzilla.redhat.com/show_bug.cgi?id=497593 .
However, I then switched tracks to work on the old gnome-volume-control
instead. I did this because I'm trying to make as many people happy as
possible as opposed to just spending my time dug into my trench firing
at the opposition. Bastien said he'd prefer the old g-v-c, made some
good points, no-one contradicted them, so I took that on board and
worked on the old g-v-c code instead. This is substantially more complex
than packaging gnome-alsamixer, and I posted some progress messages to
which no-one replied or made any helpful suggestions or contributed any
fixes, but I persevered and had it ready the next day. That's
https://bugzilla.redhat.com/show_bug.cgi?id=498136 . It's sitting there
waiting to be approved now.
If other people had spent time contributing to this process while I was
busy as fuck hacking on two different packages, tracking down patches,
and simultaneously working with Lennart and a dozen end users to
generate and track useful bug reports on the volume issues, maybe it
would have gone faster. I am terribly terribly sorry that I wasn't quite
able to meet your schedule while I was working thirteen hours a day on
this issue.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4 p.m.
Adam Williamson (awilliam(a)redhat.com) said:
I never said it was good. I said it was less bad than EXPECTING
PEOPLE
TO TELEPATHICALLY DISCOVER THE EXISTENCE OF alsamixer.
Well, I'm assuming it would be documented in the same way you'd document
'install this package and twiddle this switch'; once you're to that
point of writing up a 'fix this' cookbook, the specifics are less relevant.
If other people had spent time contributing to this process while I
was
busy as fuck hacking on two different packages, tracking down patches,
and simultaneously working with Lennart and a dozen end users to
generate and track useful bug reports on the volume issues, maybe it
would have gone faster. I am terribly terribly sorry that I wasn't quite
able to meet your schedule while I was working thirteen hours a day on
this issue.
The point isn't the amount of work going in, or anything like that; it's
more the fact that the *process* to start the change was started this
late. That indicates a real issue with the process; we've got feature
pages that define what we're trying to implement, and contingency plans
to enact if they don't work. Why did we miss the deadline to enact this
here? Was the feature page not complete enough as to what was required?
Was the time too short between alpha/beta/preview? Were the reports just
late?
It'd be the same response if we were changing the artwork now, or
attempting to do the empathy/pidgin flop at this stage, etc. It's
just rather late to be making any changes of this sort, regardless
of the work being done.
Bill
6:46 p.m.
Bill Nottingham wrote:
That indicates a real issue with the process; we've got feature
pages that define what we're trying to implement, and contingency plans
to enact if they don't work. Why did we miss the deadline to enact this
here?
I think everyone is asking the same thing at this point.
It'd be the same response if we were changing the artwork now, or
attempting to do the empathy/pidgin flop at this stage, etc. It's
just rather late to be making any changes of this sort, regardless
of the work being done.
Bill
What matters most the quality of the product or the deadline? It sounds
like the deadline supersedes all else. Better late than never, as the
saying goes.
4:32 a.m.
On Thu, 2009-04-30 at 17:00 -0400, Bill Nottingham wrote:
The point isn't the amount of work going in, or anything like
that; it's
more the fact that the *process* to start the change was started this
late. That indicates a real issue with the process; we've got feature
pages that define what we're trying to implement, and contingency plans
to enact if they don't work. Why did we miss the deadline to enact this
here? Was the feature page not complete enough as to what was required?
Was the time too short between alpha/beta/preview? Were the reports just
late?
There were a number of individual reports of regressions, but it wasn't
until quite late in the day that we realised just how bad the new mixer
was, and that something really had to be done to restore the lost
functionality.
There seemed to be a policy of closing bugs WONTFIX and telling people
that their use case, which used to work in F-10 and now doesn't, is not
appropriate for Fedora. That seems to include my own report of "I want
to be able to turn my volume up past 80%", as far as I can tell.
That approach to bugs managed to hide the problem for a little while,
which meant that we (FESCo) didn't back out the feature in good time and
just revert to the old mixer, as we probably should have done.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
5:31 a.m.
David Woodhouse wrote:
On Thu, 2009-04-30 at 17:00 -0400, Bill Nottingham wrote:
> The point isn't the amount of work going in, or anything like that; it's
> more the fact that the *process* to start the change was started this
> late. That indicates a real issue with the process; we've got feature
> pages that define what we're trying to implement, and contingency plans
> to enact if they don't work. Why did we miss the deadline to enact this
> here? Was the feature page not complete enough as to what was required?
> Was the time too short between alpha/beta/preview? Were the reports just
> late?
There were a number of individual reports of regressions, but it wasn't
until quite late in the day that we realised just how bad the new mixer
was, and that something really had to be done to restore the lost
functionality.
There seemed to be a policy of closing bugs WONTFIX and telling people
that their use case, which used to work in F-10 and now doesn't, is not
appropriate for Fedora. That seems to include my own report of "I want
to be able to turn my volume up past 80%", as far as I can tell.
Feel lucky,
on my FC11 test system, audio stopped working.
That approach to bugs managed to hide the problem for a little
while,
which meant that we (FESCo) didn't back out the feature in good time and
just revert to the old mixer, as we probably should have done.
Me thinks, the actual cause behind all this is a lack of a "sense of
reality", a "reality/wishful thinking mismatch", and a lack of culture
to learn from "errors".
It might be news to some people, but "trial and error" comprises
"errors" and "backtracking" from errors. It doesn't comprise being
stubborn and pressing stuff through at any price, just because "things
must work".
IMO, pulseaudio volume control is such case: Back to the drawing board -
It's not ready for prime time.
Other such cases in FC11, IMHO are: "no tap" and "no zap".
Ralf
9:20 a.m.
David Woodhouse (dwmw2(a)infradead.org) said:
There were a number of individual reports of regressions, but it
wasn't
until quite late in the day that we realised just how bad the new mixer
was, and that something really had to be done to restore the lost
functionality.
OK, there were regressions, but we didn't see until too late...
There seemed to be a policy of closing bugs WONTFIX and telling
people
that their use case, which used to work in F-10 and now doesn't, is not
appropriate for Fedora. That seems to include my own report of "I want
to be able to turn my volume up past 80%", as far as I can tell.
... because of how The Evil They handled the bugs ...
That approach to bugs managed to hide the problem for a little
while,
which meant that we (FESCo) didn't back out the feature in good time and
just revert to the old mixer, as we probably should have done.
... which hid the issues during the proper time to handle it.
Too bad the WONTFIX bug that prompted your screed (and frankly, I agree with
the WONTFIX in this case) wasn't filed until AFTER THE FINAL DEVEL FREEZE.
Hey, if you didn't have time to test, that's OK. Not everyone does.
But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis
based on *KNOWN* inaccuracies doesn't help.
Bill
10:06 a.m.
Bill Nottingham (notting(a)redhat.com) said:
Hey, if you didn't have time to test, that's OK. Not everyone
does.
But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis
based on *KNOWN* inaccuracies doesn't help.
Looking over the WONTFIXes:
- yours (filed 04/17, closed 04/23)
- 486500 (closed WONTFIX for F10, should work in F11)
- 477938 (closed WONTFIX for F10, should work in F11)
- 460798 (string change, not relevant for functionality)
- 455207 (closed WONTFIX for F9, should work in F11)
- 454217 (closed WONTFIX for F9, should work in F11)
(note, at this point we're in old F8 and F9 bugs)
- 451633 (apps linked statically against ancient esound don't work. Don't do
that!)
- 450610 (appears that you can do what the reporter wanted in any case)
- 448509 (padsp has issues with some binary-only apps)
- 444684 (fixed differently, in a F9 update)
- 422741 (EOL distro)
- 411151 (fixed by going to autospawning)
Hm, perhaps the NOTABUGs for PA and gnome-media?
- 488779 (PA handles volume differently; as stated, it is not a bug)
- 492757 (user tried again, it worked)
- 492790 (KVM bug for not properly using PA)
- 493978 (debug spew, toned down in later builds in any case)
- 494112 (mplayer adjusts the wrong volume control -> mplayer bug)
- 494116 (filed against wrong component)
- 494684 (config error, didn't reoccur)
- 494747 (VMWare bug)
- 494975 (config error)
- 495806 (PEBKAC, according to reporter)
- 496467 (driver bug)
- 497089 (went away in later rawhide)
- 497177 (permission problem, fixed elsewhere)
- 469335 (RT option intentionally not exposed; seems reasonable)
- 469549 (config error)
- 469677 (other app holding card open)
- 470707 (libflashsupport needed for closed flash)
- 474397 (PEBKAC)
- 476429 (config error)
- 476848 (debug spew, toned down in later builds in any case)
- 479162 (flash, missing packages not installed)
- 479492 (error in driver init)
- 480499 (flash bug)
- 480875 (other app holding card open)
- 484332 (half-mixed rawhide & f10 system had dep issues)
- 485475 (output profiles not shown in mixer - will be added later)
- 486525 (misunderstanding of command-line options)
- 487270 (driver bug)
- 488770 (output profiles not shown in mixer - will be added later)
- 483231 (complaining that applet -> notification area moved it in the panel)
- 489546 (filed against wrong component)
- 494340 (volume control requires PA)
- 494709 (misunderstanding of new flat volume support)
- 497053 (volume control requires PA)
So, looking at the bugs that could possibly be categorized as 'regressions'
or 'we don't support that use case yet' (not that I necessarily agree) were
closed WONTFIX or NOTABUG, we have:
496284 - filed 04/17, closed 04/23
485475 - filed 02/13, closed 02/17
488770 - filed 03/05, closed 03/19
That's 3 bugs, as far as I can tell, that were closed in this manner. (And the
last two are really duplicates). So, what am I missing?
Bill
10:18 a.m.
On Fri, 2009-05-01 at 10:20 -0400, Bill Nottingham wrote:
Hey, if you didn't have time to test, that's OK. Not everyone
does.
But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis
based on *KNOWN* inaccuracies doesn't help.
Oh, fun. I was hoping when I went to bed last night that my last post
won the thread, but of course it's more fun for everyone to tactically
ignore it and continue tearing strips out of each other.
Please, if you want to continue this debate, address my point that the
desktop objection that it's "bad UI" to ship multiple volume control
applications by default holds precisely no water, on the basis that they
have already been shipping multiple volume controls by default since F8
- gnome-volume-control and pavucontrol.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:48 a.m.
Adam Williamson (awilliam(a)redhat.com) said:
On Fri, 2009-05-01 at 10:20 -0400, Bill Nottingham wrote:
> Hey, if you didn't have time to test, that's OK. Not everyone does.
> But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis
> based on *KNOWN* inaccuracies doesn't help.
Oh, fun. I was hoping when I went to bed last night that my last post
won the thread, but of course it's more fun for everyone to tactically
ignore it and continue tearing strips out of each other.
Please, if you want to continue this debate,
This post was on the subject of 'how did we get in this situation', not
the solution that was proposed. I suppose I could have split off a
separate thread for that, but ... *shrug*.
Bill
11:09 a.m.
Hey Adam,
On Fri, May 1, 2009 at 11:18 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Fri, 2009-05-01 at 10:20 -0400, Bill Nottingham wrote:
> Hey, if you didn't have time to test, that's OK. Not everyone does.
> But when we're trying to figure out real issues, Rumsfeldian pseudo-analysis
> based on *KNOWN* inaccuracies doesn't help.
Oh, fun. I was hoping when I went to bed last night that my last post
won the thread, but of course it's more fun for everyone to tactically
ignore it and continue tearing strips out of each other.
Not really sure about this winning threads business but, speaking only
for myself, I chose to ignore it in part because the thread clearly
jumped the shark when you replied to your own message at least twice.
And the rest of us likely already know about pavucontrol. Lennart
wrote it and we designed the new volume control to replace it (for our
target users). The fact that it is still currently in the menus is
almost certainly an oversight - not a confirmation that what you are
proposing is a good idea.
But frankly, at this point you're out-emailing the rest of us and
we're not going to be able to compete on these terms.
Jon
11:37 a.m.
On Fri, 2009-05-01 at 12:09 -0400, William Jon McCann wrote:
Not really sure about this winning threads business but, speaking
only
for myself, I chose to ignore it in part because the thread clearly
jumped the shark when you replied to your own message at least twice.
I do that when I realize it's important to expand on something I
mentioned only in passing.
And the rest of us likely already know about pavucontrol. Lennart
wrote it and we designed the new volume control to replace it (for our
target users). The fact that it is still currently in the menus is
almost certainly an oversight - not a confirmation that what you are
proposing is a good idea.
That doesn't explain why it shipped alongside gnome-volume-control for
the last three releases, when all along you have been telling us that
shipping two graphical volume control utilities by default is a terrible
idea that will confuse people and is bad UI.
And, I really should have anticipated your reaction. Of *course* the
correct response to me pointing out that we're already shipping two
volume control applications by default and have been for a while with no
apparent problems is not to accept that this means it's probably a
perfectly good idea to have multiple applications so long as they each
expose important functionality that the other doesn't. No, the correct
response is to say that we should immediately drop one to maintain
ideological purity.
I mean...sheesh. Are you serious? We should drop pavucontrol because
including it is an 'oversight'? Despite the fact that, as I pointed out,
gnome-volume-control has no profile support and hence you can only use
pavucontrol to switch from analog to digital output, or from analog
stereo to analog surround? And even *Lennart* advocates using it this
way, in various bug reports?
Presumably none of your 'target users' has an S/PDIF output either? Or
an analog surround sound setup?
This is just getting ridiculous.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:38 p.m.
On Fri, May 01, 2009 at 09:37:34AM -0700, Adam Williamson wrote:
That doesn't explain why it shipped alongside
gnome-volume-control for
the last three releases, when all along you have been telling us that
shipping two graphical volume control utilities by default is a terrible
idea that will confuse people and is bad UI.
You appear to be arguing on the assumption that people never make
mistakes.
And, I really should have anticipated your reaction. Of *course* the
correct response to me pointing out that we're already shipping two
volume control applications by default and have been for a while with no
apparent problems is not to accept that this means it's probably a
perfectly good idea to have multiple applications so long as they each
expose important functionality that the other doesn't. No, the correct
response is to say that we should immediately drop one to maintain
ideological purity.
How many volume control applications do you want us to ship with? The
fact that mistakes have been made in the past is not an argument for
further mistakes being made in the future.
I mean...sheesh. Are you serious? We should drop pavucontrol because
including it is an 'oversight'? Despite the fact that, as I pointed out,
gnome-volume-control has no profile support and hence you can only use
pavucontrol to switch from analog to digital output, or from analog
stereo to analog surround? And even *Lennart* advocates using it this
way, in various bug reports?
Presumably none of your 'target users' has an S/PDIF output either? Or
an analog surround sound setup?
This is just getting ridiculous.
At this point? My personal feeling is that you're being needlessly
hostile and appear to be assuming the worst of the desktop people. Can
we get back to discussing this rationally rather than simply making
observations and turning them into assertions?
--
Matthew Garrett | mjg59(a)srcf.ucam.org
7:13 p.m.
Matthew Garrett wrote:
How many volume control applications do you want us to ship with? The
fact that mistakes have been made in the past is not an argument for
further mistakes being made in the future.
To ask the dumb question... right now pavucontrol is the only way
(AFAIK) right now to change relative volume of individual apps, or
choose output device per-app. Without pavucontrol, how is this supposed
to be accomplished?
(Or are both of these being labeled "exotic" use cases that shan't be
supported OOTB?)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Will somebody get this walking carpet out of my way?!"
-- Princess Leia Organa (Star Wars IV)
7:25 p.m.
On Fri, May 01, 2009 at 07:13:20PM -0500, Matthew Woehlke wrote:
Matthew Garrett wrote:
> How many volume control applications do you want us to ship with? The
> fact that mistakes have been made in the past is not an argument for
> further mistakes being made in the future.
To ask the dumb question... right now pavucontrol is the only way
(AFAIK) right now to change relative volume of individual apps, or
choose output device per-app. Without pavucontrol, how is this supposed
to be accomplished?
Per-stream volume control seems to be present in g-v-c. I'm afraid I've
got no idea about per-stream output control - I only have one output
device available here.
(Or are both of these being labeled "exotic" use cases that
shan't be
supported OOTB?)
I don't know. I'd imagine that the first certainly isn't (given that it
seems to be supported), but you'd need to ask someone else about the
second.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
8:57 a.m.
On Sat, May 02, 2009 at 01:25:29AM +0100, Matthew Garrett wrote:
On Fri, May 01, 2009 at 07:13:20PM -0500, Matthew Woehlke wrote:
> Matthew Garrett wrote:
>> How many volume control applications do you want us to ship with? The
>> fact that mistakes have been made in the past is not an argument for
>> further mistakes being made in the future.
>
> To ask the dumb question... right now pavucontrol is the only way
> (AFAIK) right now to change relative volume of individual apps, or
> choose output device per-app. Without pavucontrol, how is this supposed
> to be accomplished?
Per-stream volume control seems to be present in g-v-c. I'm afraid I've
got no idea about per-stream output control - I only have one output
device available here.
> (Or are both of these being labeled "exotic" use cases that shan't be
> supported OOTB?)
I don't know. I'd imagine that the first certainly isn't (given that it
seems to be supported), but you'd need to ask someone else about the
second.
It would be a shame if the second was considered exotic, since it's
supposed to be a feature of PulseAudio. I used it to create this:
https://fedoraproject.org/wiki/How_to_make_a_podcast
Of course, if I understand correctly, you're not saying pavucontrol
would disappear, just that the design considerations under discussion
might call for it to not be installed by default. Right?
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
9:27 a.m.
On Sat, May 02, 2009 at 09:57:34AM -0400, Paul W. Frields wrote:
Of course, if I understand correctly, you're not saying
pavucontrol
would disappear, just that the design considerations under discussion
might call for it to not be installed by default. Right?
I'm not on the desktop team, but I guess it wouldn't be impossible. I'm
actually surprised to find that it's installed by default - seeing it in
the menu, I'd assumed that it just opened the same preferences as g-v-c
does. The degree of overlap of functionality is pretty huge.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:52 a.m.
On Sat, 02.05.09 15:27, Matthew Garrett (mjg(a)redhat.com) wrote:
On Sat, May 02, 2009 at 09:57:34AM -0400, Paul W. Frields wrote:
> Of course, if I understand correctly, you're not saying pavucontrol
> would disappear, just that the design considerations under discussion
> might call for it to not be installed by default. Right?
I'm not on the desktop team, but I guess it wouldn't be impossible. I'm
actually surprised to find that it's installed by default - seeing it in
the menu, I'd assumed that it just opened the same preferences as g-v-c
does. The degree of overlap of functionality is pretty huge.
pavucontrol should have been dropped from the default install the
minute the new g-v-c was pushed into Fedora. We forgot to do that. We
should do it now. End of story.
The reason I initially wrote pavucontrol is to have something to show
off the features PA has. Such as per-stream vol control, moving
streams between devices, profile switching, ... I didn't write it because
I thought that it's the way volume controls should be looking like. I
honestly don't like writing UI programs. My interests lie elsewhere. I
wrote it as a show case, not for UIs but for what PA can be good for.
pavucontrol is more powerful than g-v-c. But that's expected. I hope
g-v-c will eventually learn more of the features pavucontrol has
without becoming as cluttered, so that we can get rid of pavucontrol
eventually.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:46 a.m.
On Sat, 2009-05-02 at 16:52 +0200, Lennart Poettering wrote:
On Sat, 02.05.09 15:27, Matthew Garrett (mjg(a)redhat.com) wrote:
>
> On Sat, May 02, 2009 at 09:57:34AM -0400, Paul W. Frields wrote:
>
> > Of course, if I understand correctly, you're not saying pavucontrol
> > would disappear, just that the design considerations under discussion
> > might call for it to not be installed by default. Right?
>
> I'm not on the desktop team, but I guess it wouldn't be impossible. I'm
> actually surprised to find that it's installed by default - seeing it in
> the menu, I'd assumed that it just opened the same preferences as g-v-c
> does. The degree of overlap of functionality is pretty huge.
pavucontrol should have been dropped from the default install the
minute the new g-v-c was pushed into Fedora. We forgot to do that. We
should do it now. End of story.
So what do we do about profile switching - digital output, analog
surround output?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:39 p.m.
On Sat, 2009-05-02 at 09:46 -0700, Adam Williamson wrote:
On Sat, 2009-05-02 at 16:52 +0200, Lennart Poettering wrote:
> On Sat, 02.05.09 15:27, Matthew Garrett (mjg(a)redhat.com) wrote:
>
> >
> > On Sat, May 02, 2009 at 09:57:34AM -0400, Paul W. Frields wrote:
> >
> > > Of course, if I understand correctly, you're not saying pavucontrol
> > > would disappear, just that the design considerations under discussion
> > > might call for it to not be installed by default. Right?
> >
> > I'm not on the desktop team, but I guess it wouldn't be impossible.
I'm
> > actually surprised to find that it's installed by default - seeing it in
> > the menu, I'd assumed that it just opened the same preferences as g-v-c
> > does. The degree of overlap of functionality is pretty huge.
>
> pavucontrol should have been dropped from the default install the
> minute the new g-v-c was pushed into Fedora. We forgot to do that. We
> should do it now. End of story.
So what do we do about profile switching - digital output, analog
surround output?
Then you people can use the gst-mixer you're packaging, it will work
just as well (or as badly) as it used to.
4:28 a.m.
On 05/03/2009 06:09 AM, Bastien Nocera wrote:
On Sat, 2009-05-02 at 09:46 -0700, Adam Williamson wrote:
> So what do we do about profile switching - digital output,
analog
> surround output?
Then you people can use the gst-mixer you're packaging, it will work
just as well (or as badly) as it used to.
So the recommendation is to use the old gst-mixer but the problem then
is the opposition to having it installed by default as well as the
problem of discovering it even when it is installed by default.
While you are trying to reach perfection, the current experience is a
giant regression for many users. A good compromise would be a advanced
button which calls the old gst-mixer.
Rahul
7:37 p.m.
On Sat, 2009-05-02 at 00:38 +0100, Matthew Garrett wrote:
On Fri, May 01, 2009 at 09:37:34AM -0700, Adam Williamson wrote:
> That doesn't explain why it shipped alongside gnome-volume-control for
> the last three releases, when all along you have been telling us that
> shipping two graphical volume control utilities by default is a terrible
> idea that will confuse people and is bad UI.
You appear to be arguing on the assumption that people never make
mistakes.
Doing something you say is a fundamental interface booboo for three
straight releases is a pretty big mistake. I don't believe this was a
mistake, I believe it was intentional - we want to ship the shiny new
Pulse stuff. And that's fine. It just means the arbitrary "no multiple
mixers" argument that's now being used to oppose gst-mixer /
gnome-alsamixer is an argument of convenience.
> And, I really should have anticipated your reaction. Of *course*
the
> correct response to me pointing out that we're already shipping two
> volume control applications by default and have been for a while with no
> apparent problems is not to accept that this means it's probably a
> perfectly good idea to have multiple applications so long as they each
> expose important functionality that the other doesn't. No, the correct
> response is to say that we should immediately drop one to maintain
> ideological purity.
How many volume control applications do you want us to ship with? The
fact that mistakes have been made in the past is not an argument for
further mistakes being made in the future.
Frankly, now I've noticed we *already* have two, I'm inclined to favour
the "drop the new gnome-volume-control entirely" argument, if you want
to keep the number of mixers down. Here's the problem. There are two
really important use cases that gnome-volume-control doesn't cover:
profile switching - i.e. enabling digital output (or analog surround on
cards that do that, but that's not *so* important), and input switching.
Legacy mixers - gnome-alsamixer / gst-mixer - handle both of these cases
and everything else you'd want to do with a mixer. Just not very well,
but hey, at least it's the same crappy interface people have been used
to for a decade.
pavucontrol does profile switching, and does it in a very nice way,
thanks to the work done on Pulse during this cycle. But it doesn't do
input switching.
gnome-volume-control doesn't do profile switching *or* input switching.
So the only mixers we have that actually cover these really basic use
cases are the legacy ones. If you're completely wedded to the new g-v-c,
but we want people to be able to do input switching and use digital
output, we'd need at least two mixers: g-v-c and a legacy mixer. But
then we lose pavucontrol's nice profile switching, which is a bit of a
shame.
Frankly, the combination that appears to combine the most actual
usability with PulseAudio niceness is pavucontrol + a legacy mixer.
g-v-c, in functional terms, has exactly no advantages over either
pavucontrol or the legacy mixers. Its *only* advantage is that it's a
more standard-following GNOME interface than pavucontrol. Whoopee. I
don't think that outweighs the fact that it's missing two really
important features. I've been ignoring digital output throughout this
whole debate because Lennart had argued me out of that one in the
initial bug report I filed, but I forgot that his argument depended on
pavucontrol.
Summary: legacy mixers do everything with a crap interface, pavucontrol
does everything except one big thing with a quite nice interface, g-v-c
misses two big things and has a marginally nicer interface than
pavucontrol. Given that, my opinion is that the options "pavucontrol +
legacy mixer" or just "legacy mixer alone" are tied in niceness, and any
combination involving the new g-v-c falls rather near the bottom of the
pile...
> I mean...sheesh. Are you serious? We should drop pavucontrol
because
> including it is an 'oversight'? Despite the fact that, as I pointed out,
> gnome-volume-control has no profile support and hence you can only use
> pavucontrol to switch from analog to digital output, or from analog
> stereo to analog surround? And even *Lennart* advocates using it this
> way, in various bug reports?
>
> Presumably none of your 'target users' has an S/PDIF output either? Or
> an analog surround sound setup?
>
> This is just getting ridiculous.
At this point? My personal feeling is that you're being needlessly
hostile and appear to be assuming the worst of the desktop people. Can
we get back to discussing this rationally rather than simply making
observations and turning them into assertions?
I'd love to be discussing it rationally, but I don't think you guys are.
I still haven't seen a convincing refutation of the "we already have
multiple mixers" point besides "it's a mistake" - which, even if
it's
true, makes you guys look rather bad, as it's a fairly large mistake (by
your own standards) in three straight stable releases...which doesn't
actually seem to have caused any problems, I certainly haven't seen
anyone complaining that the presence of pavucontrol alongside
gnome-volume-control confused them, in F8, F9, or F10. Where does that
leave the "multiple mixers are bad by definition" argument? Even if it
*was* a mistake, the fact that it's been in the distro for three
releases without apparently causing any trainwrecks seems rather
significant to me.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:55 p.m.
Put simply, any argument based on "Nobody's complained, so it's fine" is
fallacious. People expect Linux to be dreadful. If something works
they're happy - if it doesn't, it's because Linux isn't ready for the
desktop yet. And when we've still got a community that's more inclined
to tell people that they should read the documentation rather than ask
whether a specific UI is sufficiently understandable, it's hardly
unsurprisingly that people aren't going to spend a great deal of time
complaining about how unintuitive they found some aspect of UI.
If people raise issues with a suggestion and the counterargument is
"Users haven't raised this problem" then we can't draw conclusions about
why they haven't. Maybe it's because the average user is smart enough to
figure out that the multitude of volume controls we ship are all
intended for subtly different purposes. Maybe it's because they can't be
bothered filing bugs. Maybe it's because they're scared of raising a
contentious subject. Who knows? In the end we still come down to making
decisions based on the opinions of people we deem to be experts in the
field. And if you don't trust the desktop team to make the appropriate
decision in this case then it would be helpful for you to say so
plainly.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:17 a.m.
On Sat, 2009-05-02 at 01:55 +0100, Matthew Garrett wrote:
Put simply, any argument based on "Nobody's complained, so
it's fine" is
fallacious. People expect Linux to be dreadful. If something works
they're happy - if it doesn't, it's because Linux isn't ready for the
desktop yet. And when we've still got a community that's more inclined
to tell people that they should read the documentation rather than ask
whether a specific UI is sufficiently understandable, it's hardly
unsurprisingly that people aren't going to spend a great deal of time
complaining about how unintuitive they found some aspect of UI.
If people raise issues with a suggestion and the counterargument is
"Users haven't raised this problem" then we can't draw conclusions
about
why they haven't. Maybe it's because the average user is smart enough to
figure out that the multitude of volume controls we ship are all
intended for subtly different purposes. Maybe it's because they can't be
bothered filing bugs. Maybe it's because they're scared of raising a
contentious subject. Who knows? In the end we still come down to making
decisions based on the opinions of people we deem to be experts in the
field. And if you don't trust the desktop team to make the appropriate
decision in this case then it would be helpful for you to say so
plainly.
Let's see. I don't think you're really wrong. It's not a perfect basis
for argument. However, let me see if I can summarize the desktop team's
position:
"We're in the best position to know what's right for the desktop, and we
say that the best thing to do is just ship one mixer application. The
one that can't handle anything except analog stereo output when there's
no problem with ALSA. We consider surround output, digital output, input
switching, input monitoring and all the known and as-yet unknown but
undoubtedly existent cases where there *is* a problem with the ALSA
mixer and hence g-v-c doesn't work properly to be, as a whole, not
significant enough to make it worthwhile shipping a different mixer,
either alongside g-v-c or instead of it.
We're the best people to make the decision because we know what we're
doing when it comes to building a desktop. Yes, we've actually been
shipping two mixers by default for three releases now (and we didn't
notice this until someone else pointed it out), but that's just, er, a
mistake. We're still the *only* ones who can be trusted to know what
we're doing here!"
I'm really, honestly, not in a nasty way, not finding that to be 100%
convincing.
I'm not working on the basis of "do I trust the desktop team to make
this decision and get it right". That's not really how I'm looking at
it. I'm just evaluating this particular case, on its merits, and I don't
think the call that the desktop team made was the right one. I don't
really care about the reasons behind that or the politics or yadda yadda
yadda. I certainly agree that the process could have been managed better
- objections could have been raised much earlier - and that's something
it's entirely worth dissecting...but I don't think it should take
precedence over making sure Fedora 11 is the best product it can be. I
just don't think shipping a mixer that doesn't handle analog surround
output, digital output, input switching, input monitoring or the
multiple cases of buggy volume supplied by ALSA (there's six of these
bugs filed so far, btw, and counting) as our *only* graphical mixer is a
good decision.
I raised this concern through the proper channels, it was picked up by
FESco - not at my instigation, btw, I was called into the meeting after
the topic had already come up - and FESco came out in the same position
I've been espousing. At that point I thought the whole thing was settled
and I went on to actually work on the technical side of what needing
doing, whereupon the whole argument got dragged out of its grave on this
list and we had to go through everything again, three times over.
I'm sorry if I don't handle the political side of things that greatly,
and I'm sorry if I sometimes come off as too aggressive. That's my
fault. I'm not trying to rub anyone up the wrong way. It's just a bit
frustrating that no-one seems to want to engage in the actual blood and
guts of this issue; all I'm hearing is vague theoretical arguments about
why *this* group of people is better entitled to make the decision or
why *that* line of argument is theoretically flawed or yadda yadda. I'm
just not finding it very productive.
Please credit me with a bit of experience and knowledge in this field
too...yes, I've not been around Fedora very long, but I *have* been on
the very sharp and pointy end of distribution releases at Another Place
for three or four years, being The Guy for several tens of thousands of
people to yell at when they don't like something in a new release, also
being the guy who tracks release critical bugs and writes all the
release documentation, including the Errata. I think I have a pretty
decent track record of knowing a hot-button issue when I see one, and
the idea that we should ship the new gnome-volume-control as our sole
GUI volume control application on the desktop operating system images
that most people think of as 'Fedora' (the default install you get off
the DVD, and the GNOME live spin - the live spin you get if you don't
explicitly select a different one, and the one we mostly hand out at
events, covered in Fedora logos) just does not feel like a winning
proposition to me. All I've been trying to do is back that position up
with solid reasoning and logic.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:24 a.m.
On Sat, 2009-05-02 at 01:55 +0100, Matthew Garrett wrote:
Put simply, any argument based on "Nobody's complained, so
it's fine" is
fallacious. People expect Linux to be dreadful. If something works
they're happy - if it doesn't, it's because Linux isn't ready for the
desktop yet. And when we've still got a community that's more inclined
to tell people that they should read the documentation rather than ask
whether a specific UI is sufficiently understandable, it's hardly
unsurprisingly that people aren't going to spend a great deal of time
complaining about how unintuitive they found some aspect of UI.
If people raise issues with a suggestion and the counterargument is
"Users haven't raised this problem" then we can't draw conclusions
about
why they haven't. Maybe it's because the average user is smart enough to
figure out that the multitude of volume controls we ship are all
intended for subtly different purposes. Maybe it's because they can't be
bothered filing bugs. Maybe it's because they're scared of raising a
contentious subject. Who knows? In the end we still come down to making
decisions based on the opinions of people we deem to be experts in the
field. And if you don't trust the desktop team to make the appropriate
decision in this case then it would be helpful for you to say so
plainly.
Let's see. I don't think you're really wrong. It's not a perfect basis
for argument. However, let me see if I can summarize the desktop team's
position:
"We're in the best position to know what's right for the desktop, and we
say that the best thing to do is just ship one mixer application. The
one that can't handle anything except analog stereo output when there's
no problem with ALSA. We consider surround output, digital output, input
switching, input monitoring and all the known and as-yet unknown but
undoubtedly existent cases where there *is* a problem with the ALSA
mixer and hence g-v-c doesn't work properly to be, as a whole, not
significant enough to make it worthwhile shipping a different mixer,
either alongside g-v-c or instead of it.
We're the best people to make the decision because we know what we're
doing when it comes to building a desktop. Yes, we've actually been
shipping two mixers by default for three releases now (and we didn't
notice this until someone else pointed it out), but that's just, er, a
mistake. We're still the *only* ones who can be trusted to know what
we're doing here!"
I'm really, honestly, not in a nasty way, not finding that to be 100%
convincing.
I'm not working on the basis of "do I trust the desktop team to make
this decision and get it right". That's not really how I'm looking at
it. I'm just evaluating this particular case, on its merits, and I don't
think the call that the desktop team made was the right one. I don't
really care about the reasons behind that or the politics or yadda yadda
yadda. I certainly agree that the process could have been managed better
- objections could have been raised much earlier - and that's something
it's entirely worth dissecting...but I don't think it should take
precedence over making sure Fedora 11 is the best product it can be. I
just don't think shipping a mixer that doesn't handle analog surround
output, digital output, input switching, input monitoring or the
multiple cases of buggy volume supplied by ALSA (there's six of these
bugs filed so far, btw, and counting) as our *only* graphical mixer is a
good decision.
I raised this concern through the proper channels, it was picked up by
FESco - not at my instigation, btw, I was called into the meeting after
the topic had already come up - and FESco came out in the same position
I've been espousing. At that point I thought the whole thing was settled
and I went on to actually work on the technical side of what needing
doing, whereupon the whole argument got dragged out of its grave on this
list and we had to go through everything again, three times over.
I'm sorry if I don't handle the political side of things that greatly,
and I'm sorry if I sometimes come off as too aggressive. That's my
fault. I'm not trying to rub anyone up the wrong way. It's just a bit
frustrating that no-one seems to want to engage in the actual blood and
guts of this issue; all I'm hearing is vague theoretical arguments about
why *this* group of people is better entitled to make the decision or
why *that* line of argument is theoretically flawed or yadda yadda. I'm
just not finding it very productive.
Please credit me with a bit of experience and knowledge in this field
too...yes, I've not been around Fedora very long, but I *have* been on
the very sharp and pointy end of distribution releases at Another Place
for three or four years, being The Guy for several tens of thousands of
people to yell at when they don't like something in a new release, also
being the guy who tracks release critical bugs and writes all the
release documentation, including the Errata. I think I have a pretty
decent track record of knowing a hot-button issue when I see one, and
the idea that we should ship the new gnome-volume-control as our sole
GUI volume control application on the desktop operating system images
that most people think of as 'Fedora' (the default install you get off
the DVD, and the GNOME live spin - the live spin you get if you don't
explicitly select a different one, and the one we mostly hand out at
events, covered in Fedora logos) just does not feel like a winning
proposition to me. All I've been trying to do is back that position up
with solid reasoning and logic.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:37 a.m.
On Saturday 02 May 2009 01:55:40 Matthew Garrett wrote:
And if you don't trust the desktop team to make the appropriate
decision in this case then it would be helpful for you to say so
plainly.
Matthew,
I'm not picking on you, but as someone standing on the outside looking in,
Adam seems to be making structured, reasoned arguments. From my perspective,
he appears to be speaking for my interests. I think the Desktop team might be
rather surprised how many people do use line-in and would like a mixer
installed by default that allows input switching. I've bit my tongue a couple
of times whilst reading some of the mixer 'discussion' on the list. It seems
to me that most of the people posting with a redhat.com address don't seem to
have much of an idea what users (not developers) actually do use a mixer for.
ie. not just increasing/decreasing volume levels. And for the record, I'm a
fan of Pulseaudio!
Regards
Clive
11:56 a.m.
On Sat, 2009-05-02 at 01:55 +0100, Matthew Garrett wrote:
In the end we still come down to making
decisions based on the opinions of people we deem to be experts in the
field. And if you don't trust the desktop team to make the appropriate
decision in this case then it would be helpful for you to say so
plainly.
Well, to put it bluntly, no. We don't trust the desktop team and we
*shouldn't* trust the desktop team.
So they're "expert in their field". Fine. Cool. We need experts. But the
problem with experts is they're totally consumed by their field, and
lack the ability to view their piece of the puzzle in the overall
picture.
There's a reason we have release managers and FESCo. Someone has to
manage the Big Picture, and sometimes that requires the "experts" to
compromise their Perfect Vision for the good of the overall project.
... And are we seriously designing UI based purely on "the opinions of
experts"? Is there any actual end user testing in the loop?
Are we honestly expected to trust the desktop team based purely on
"We're experts and we say so!" How reasonable is that? No, trusting
experts is for sheep. We want to see data. Show us usability studies, or
meta-studies of bug reports. *Something* more than "we say so". We trust
data, not experts.
As it is, the people in the trenches doing QA and user support have way
more convincing data than the desktop team.
Designing HCI without Humans in the loop is bogus beyond belief.
12:11 p.m.
Hi,
On Sun, May 3, 2009 at 12:56 PM, Callum Lerwick <seg(a)haxxed.com> wrote:
On Sat, 2009-05-02 at 01:55 +0100, Matthew Garrett wrote:
> In the end we still come down to making
> decisions based on the opinions of people we deem to be experts in the
> field. And if you don't trust the desktop team to make the appropriate
> decision in this case then it would be helpful for you to say so
> plainly.
Well, to put it bluntly, no. We don't trust the desktop team and we
*shouldn't* trust the desktop team.
So they're "expert in their field". Fine. Cool. We need experts. But the
problem with experts is they're totally consumed by their field, and
lack the ability to view their piece of the puzzle in the overall
picture.
There's a reason we have release managers and FESCo. Someone has to
manage the Big Picture, and sometimes that requires the "experts" to
compromise their Perfect Vision for the good of the overall project.
... And are we seriously designing UI based purely on "the opinions of
experts"? Is there any actual end user testing in the loop?
Are we honestly expected to trust the desktop team based purely on
"We're experts and we say so!" How reasonable is that? No, trusting
experts is for sheep. We want to see data. Show us usability studies, or
meta-studies of bug reports. *Something* more than "we say so". We trust
data, not experts.
As it is, the people in the trenches doing QA and user support have way
more convincing data than the desktop team.
Designing HCI without Humans in the loop is bogus beyond belief.
I think you are conflating user experience design with usability. Our
user experience design and interface design takes place very early in
the Fedora development cycle. It is primarily informed by our
experiences, research, and vision. Currently, the user testing is
done primarily after a Fedora release. However, we don't have a
process in place to collect trustworthy, actionable data. Ubuntu has
actually just completed a round of real user testing and will be
presenting the results at GUADEC. So, that should be interesting.
It would be great if we organized something similar. A word of
caution though - this is hard to do correctly. It is quite easy to
collect misleading and confusing data. The exact process of the
testing matters a great deal. FWIW, I'm hoping to do something like
this in the next few months.
Jon
12:07 a.m.
William Jon McCann wrote:
Hi,
On Sun, May 3, 2009 at 12:56 PM, Callum Lerwick <seg(a)haxxed.com> wrote:
> As it is, the people in the trenches doing QA and user support
have way
> more convincing data than the desktop team.
>
> Designing HCI without Humans in the loop is bogus beyond belief.
I think you are conflating user experience design with usability. Our
user experience design and interface design takes place very early in
the Fedora development cycle. It is primarily informed by our
experiences, research, and vision. Currently, the user testing is
done primarily after a Fedora release.
IMNSHO, this is a serious defect of the
development process.
Your remark also explains a lot of the (IMNSHO) silly decisions and
regressions Fedora desktop users are being confronted with.
Simply deviate a "mu" from the desktop team developers'
use-cases/hw/setup and you are likely to get stuck somewhere.
It would be great if we organized something similar.
You
already have an essential component of it: It's called user
feedback. It's up to those in charge to take it into account or to
ignoring it. I regret having to say so, but I feel the latter is what is
happening to a wide extend.
A word of
caution though - this is hard to do correctly.
Right, but it's pretty easy to
identify errors and regressions.
The problem is developers to draw consequences from them.
It is quite easy to
collect misleading and confusing data. The exact process of the
testing matters a great deal. FWIW, I'm hoping to do something like
this in the next few months.
Glad to hear this. To me, it's very apparent that
much of recent years'
RH/GNOME desktop works have hardly seen much usability testing before
pushing them into Fedora.
Ralf
8:40 p.m.
Once upon a time, Adam Williamson <awilliam(a)redhat.com> said:
pavucontrol does profile switching, and does it in a very nice way,
thanks to the work done on Pulse during this cycle. But it doesn't do
input switching.
gnome-volume-control doesn't do profile switching *or* input switching.
If pavucontrol existed and worked better, why did we get yet another
audio control written from scratch? Why not just work on one of the
many existing ones (like pavucontrol that already knows how to talk to
PA)?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:42 p.m.
On Fri, May 01, 2009 at 08:40:29PM -0500, Chris Adams wrote:
Once upon a time, Adam Williamson <awilliam(a)redhat.com> said:
> pavucontrol does profile switching, and does it in a very nice way,
> thanks to the work done on Pulse during this cycle. But it doesn't do
> input switching.
>
> gnome-volume-control doesn't do profile switching *or* input switching.
If pavucontrol existed and worked better, why did we get yet another
audio control written from scratch? Why not just work on one of the
many existing ones (like pavucontrol that already knows how to talk to
PA)?
I wonder how hard it would be to add input switching to
pavucontrol...then we could ditch g-v-c and the legacy mixers and keep
the one pavucontrol that handles all the use cases...
3:47 a.m.
On 05/02/2009 03:42 AM, Chuck Anderson wrote:
I wonder how hard it would be to add input switching to
pavucontrol...then we could ditch g-v-c and the legacy mixers and keep
the one pavucontrol that handles all the use cases...
It's not just input switching. Skype is usless if I can't enable the mic
boost, and general volume output is too low on my T61 because the
'hidden' PCM slider is set at an arbitrarily low value.
-denis
4:02 a.m.
It's not just input switching. Skype is usless if I can't
enable the mic
boost, and general volume output is too low on my T61 because the 'hidden'
PCM slider is set at an arbitrarily low value.
Report it, it will be fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=497966
Regards,
----------
Mathieu Bridon (bochecha)
8:59 a.m.
On Sat, May 02, 2009 at 11:02:12 +0200,
"Mathieu Bridon (bochecha)" <bochecha(a)fedoraproject.org> wrote:
> It's not just input switching. Skype is usless if I
can't enable the mic
> boost, and general volume output is too low on my T61 because the 'hidden'
> PCM slider is set at an arbitrarily low value.
Report it, it will be fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=497966
More specificly there is a bug to combine master and pcm controls into
one slider:
https://bugzilla.redhat.com/show_bug.cgi?id=497945
11:46 a.m.
On Sat, 2009-05-02 at 11:02 +0200, Mathieu Bridon (bochecha) wrote:
> It's not just input switching. Skype is usless if I
can't enable the mic
> boost, and general volume output is too low on my T61 because the 'hidden'
> PCM slider is set at an arbitrarily low value.
Report it, it will be fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=497966
We already have a report for the T61, in fact.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:34 a.m.
Denis Leroy wrote:
On 05/02/2009 03:42 AM, Chuck Anderson wrote:
> I wonder how hard it would be to add input switching to
> pavucontrol...then we could ditch g-v-c and the legacy mixers and keep
> the one pavucontrol that handles all the use cases...
It's not just input switching. Skype is usless if I can't enable the mic
boost, and general volume output is too low on my T61 because the
'hidden' PCM slider is set at an arbitrarily low value.
Could that be the same issue as I am facing it?
cf. https://bugzilla.redhat.com/show_bug.cgi?id=498699
I had to rm -rf ~/.pulse to get PCM volume up to a usable level.
Ralf
5:34 a.m.
On Fri, 2009-05-01 at 21:42 -0400, Chuck Anderson wrote:
On Fri, May 01, 2009 at 08:40:29PM -0500, Chris Adams wrote:
> Once upon a time, Adam Williamson <awilliam(a)redhat.com> said:
> > pavucontrol does profile switching, and does it in a very nice way,
> > thanks to the work done on Pulse during this cycle. But it doesn't do
> > input switching.
> >
> > gnome-volume-control doesn't do profile switching *or* input switching.
>
> If pavucontrol existed and worked better, why did we get yet another
> audio control written from scratch? Why not just work on one of the
> many existing ones (like pavucontrol that already knows how to talk to
> PA)?
I wonder how hard it would be to add input switching to
pavucontrol...then we could ditch g-v-c and the legacy mixers and keep
the one pavucontrol that handles all the use cases...
We worked on the new gnome-volume-control because pavucontrol is a "show
all the options underneath" program, just like the ALSA mixers were.
We wrote use cases, we checked what other systems did, and we intend to
present something to the user that's less complicated than showing up
all the knobs PulseAudio offers.
So shipping pavucontrol isn't a solution in itself.
9:03 a.m.
On Sat, May 02, 2009 at 11:34:16 +0100,
Bastien Nocera <bnocera(a)redhat.com> wrote:
We worked on the new gnome-volume-control because pavucontrol is a "show
all the options underneath" program, just like the ALSA mixers were.
But it shows different sets of all controls than the ALSA mixer. I found
I could use it to boost the volume, but the noise was unacceptable. It
ended up just delaying me from finding alsamixer which I could use to
really fix my problem.
7:34 p.m.
On Sat, 2009-05-02 at 09:03 -0500, Bruno Wolff III wrote:
On Sat, May 02, 2009 at 11:34:16 +0100,
Bastien Nocera <bnocera(a)redhat.com> wrote:
>
> We worked on the new gnome-volume-control because pavucontrol is a "show
> all the options underneath" program, just like the ALSA mixers were.
But it shows different sets of all controls than the ALSA mixer. I found
I could use it to boost the volume, but the noise was unacceptable. It
ended up just delaying me from finding alsamixer which I could use to
really fix my problem.
Do you realise that your answer has nothing to do with my point? I'm
talking about the usability design of gnome-volume-control, and you talk
to me about which knobs it wiggles.
11:53 a.m.
Bastien Nocera wrote:
We worked on the new gnome-volume-control because pavucontrol is a
"show
all the options underneath" program, just like the ALSA mixers were.
We wrote use cases, we checked what other systems did, and we intend to
present something to the user that's less complicated than showing up
all the knobs PulseAudio offers.
Translation:
"We worked on the new gnome-volume-control because pavucontrol has too many
features and we hate powerful applications.
So we wrote down the simplest use cases we could come up with in a short
brainstorming session and decided to remove all the useful features we
didn't think of, not asking for any actual user input, and we intend to
present a crippled user interface only showing that simplistic subset of
features."
And then you're surprised clichés about GNOME working exactly that way
circulate?
Kevin Kofler
12:27 p.m.
On Sat, May 02, 2009 at 06:53:09PM +0200, Kevin Kofler wrote:
Translation:
"We worked on the new gnome-volume-control because pavucontrol has too many
features and we hate powerful applications.
So we wrote down the simplest use cases we could come up with in a short
brainstorming session and decided to remove all the useful features we
didn't think of, not asking for any actual user input, and we intend to
present a crippled user interface only showing that simplistic subset of
features."
Actually it's because we hate freedom and apple pie. Please. This kind
of thing is unnecessary.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:47 p.m.
On Sat, 02.05.09 18:53, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
Bastien Nocera wrote:
> We worked on the new gnome-volume-control because pavucontrol is a "show
> all the options underneath" program, just like the ALSA mixers were.
>
> We wrote use cases, we checked what other systems did, and we intend to
> present something to the user that's less complicated than showing up
> all the knobs PulseAudio offers.
Translation:
"We worked on the new gnome-volume-control because pavucontrol has too many
features and we hate powerful applications.
So we wrote down the simplest use cases we could come up with in a short
brainstorming session and decided to remove all the useful features we
didn't think of, not asking for any actual user input, and we intend to
present a crippled user interface only showing that simplistic subset of
features."
And then you're surprised clichés about GNOME working exactly that way
circulate?
Oh my.
Yes, I know you like KDE. That's OK. But please, why do you feel you
have seize every opportunity to express that you think that the KDE
approach in exposing as many options as possible to the user is better
than the GNOME approach where we don't want to show too many options?
Everyone and his dog knows by now that you like to have many options
and thus are into KDE. You constant complaining and bitching about
GNOME is completely pointless -- since you don't even use it
yourself. You made your choices, and probably have good reasons for
it. Fine. No need for constantly complaining about the choices the
other camp makes.
Please, grow up and don't try to make everything a fight between KDE
and GNOME, neither directly nor between the lines!
Thank you very much,
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:47 p.m.
On Sat, 2009-05-02 at 18:53 +0200, Kevin Kofler wrote:
Bastien Nocera wrote:
> We worked on the new gnome-volume-control because pavucontrol is a "show
> all the options underneath" program, just like the ALSA mixers were.
>
> We wrote use cases, we checked what other systems did, and we intend to
> present something to the user that's less complicated than showing up
> all the knobs PulseAudio offers.
Translation:
"We worked on the new gnome-volume-control because pavucontrol has too many
features and we hate powerful applications.
So we wrote down the simplest use cases we could come up with in a short
brainstorming session and decided to remove all the useful features we
didn't think of, not asking for any actual user input, and we intend to
present a crippled user interface only showing that simplistic subset of
features."
And then you're surprised clichés about GNOME working exactly that way
circulate?
First of all, I'd appreciate if you didn't put words in my mouth.
And no, we usually don't ask for as much user input as some other
projects, because otherwise we get asked to show the old knobs for power
users, instead of having them trying to explain what they're trying to
do.
I'd advise you to read "The inmates are running the asylum" by Alan
Cooper (or "Is it just me or is everything shit?" if you're in a lighter
mood).
11:55 a.m.
On Sun, 2009-05-03 at 01:47 +0100, Bastien Nocera wrote:
First of all, I'd appreciate if you didn't put words in my
mouth.
And no, we usually don't ask for as much user input as some other
projects, because otherwise we get asked to show the old knobs for power
users, instead of having them trying to explain what they're trying to
do.
And then you explain to them why they're abnormal for even wanting to do
what they want to do! Then dismiss and ignore them. That makes them
happy!
I'd advise you to read "The inmates are running the
asylum" by Alan
Cooper (or "Is it just me or is everything shit?" if you're in a lighter
mood).
Ah yes, the chapter about arguing with your end users was a good read.
12:32 p.m.
On Sat, 2009-05-02 at 11:34 +0100, Bastien Nocera wrote:
We wrote use cases, we checked what other systems did, and we intend
to
present something to the user that's less complicated than showing up
all the knobs PulseAudio offers.
Here's the other thing that gets me about this: okay, so you thought
about the use cases you want to support and came up with a design.
Great.
But we don't even have that design yet. That design includes input
switching and profile switching. These are features that Lennart and
others have gone on the public record as saying are intended to be in
g-v-c and will be in g-v-c in future. So obviously you consider those
important use cases that we ought to be supporting.
However, you say it's perfectly fine to ship - as our only installed
graphical mixer in F11 - a mixer which *doesn't* yet have those
features.
I mean...come on! You can't just go about introducing huge functional
regressions willy-nilly because you want to have the new design in as
soon as you've finished a working prototype with half the features
missing! This isn't PulseAudio itself, where we really needed to ship
the thing before it was really done to get useful wide-based testing; in
this case we already *know* what g-v-c is missing, and those features
can be worked on without causing people the pain of suddenly losing
these features.
Frankly I'm becoming more and more in favour of advocating simply having
gnome-media build the old mixer for F11 and delay the new one entirely
until F12 (or, hell, it could go into F11 as an update if profile
switching and input switching get implemented). That's simpler (it just
requires flipping a switch in the gnome-media spec), less invasive,
satisfies the "we should only have one mixer" requirement, and is more
in line with what people apparently think the role of FESco should be
(approving or denying new features, not mandating interface
compromises).
I liked the compromise because at least we have the new mixer in there
for people to try out, and it'd help us find the
bad-default-volume-settings-from-ALSA bugs, but maybe this way would get
less resistance from both sides...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:59 p.m.
On Sat, 2009-05-02 at 10:32 -0700, Adam Williamson wrote:
On Sat, 2009-05-02 at 11:34 +0100, Bastien Nocera wrote:
> We wrote use cases, we checked what other systems did, and we intend
> to
> present something to the user that's less complicated than showing up
> all the knobs PulseAudio offers.
Here's the other thing that gets me about this: okay, so you thought
about the use cases you want to support and came up with a design.
Great.
But we don't even have that design yet. That design includes input
switching and profile switching.
Tell me where I wrote that:
https://fedoraproject.org/wiki/Features/VolumeControl#User_Experience
<snip rant>
*Where*
I already asked this question when Will made the same assumption as you
did, during the Fesco meeting. The use cases we had didn't include any
need for profile switching.
Yes we realised late we'd need it for some use cases, no, we didn't
decide to ship an unfinished volume control that we knew would impact
some use cases we didn't think of.
And we already knew that we'd need profile switching for some things
that we couldn't have before:
- out-of-the-box multi-speaker setup support
- multi-speakers testing
- Bluetooth audio profile switching and service reservation (eg. only
play stereo audio play through the headphones, and let a mobile phone
connect to the headset, music stops when you receive a call)
A couple of benefits from the current volume control compared to the old
one:
- "default" input and output control
- microphone level checks
- sound effects level control
- per-application volume control (for apps that support it)
The only use case(s) that we haven't catered for are for people who want
to record things, and the sound card has more than 1 input. Yes, it's a
big omission, but that doesn't mean you're allowed to write off the
benefits we're bringing for a large number of users already.
8:59 p.m.
On Sun, 2009-05-03 at 01:59 +0100, Bastien Nocera wrote:
> Here's the other thing that gets me about this: okay, so you
thought
> about the use cases you want to support and came up with a design.
> Great.
>
> But we don't even have that design yet. That design includes input
> switching and profile switching.
Tell me where I wrote that:
https://fedoraproject.org/wiki/Features/VolumeControl#User_Experience
<snip rant>
*Where*
I already asked this question when Will made the same assumption as you
did, during the Fesco meeting. The use cases we had didn't include any
need for profile switching.
That just makes me question even more your competence to be doing the
design; if you manage to come up with a design for a mixer application
without considering the importance of digital output, well. Er.
That's...um. My output device is connected digitally. So are zillions of
others. That's why soundcards ship with S/PDIF outputs. Even cheap
crappy onboard sound, where the manufacturers would gladly save a cent
any old way, universally include S/PDIF now - because people want it.
How were you expecting us to hear any sound?
I suspect this whole process was managed by people who are great at
interface design, and great at the software side of audio/video (which I
know you are), but perhaps didn't think hard enough about what people
actually do with audio hardware.
Yes we realised late we'd need it for some use cases, no, we
didn't
decide to ship an unfinished volume control that we knew would impact
some use cases we didn't think of.
And we already knew that we'd need profile switching for some things
that we couldn't have before:
- out-of-the-box multi-speaker setup support
- multi-speakers testing
- Bluetooth audio profile switching and service reservation (eg. only
play stereo audio play through the headphones, and let a mobile phone
connect to the headset, music stops when you receive a call)
These would all be awesome things, if they existed yet. Once they do,
life will indeed be awesome. I anticipate their arrival avidly.
A couple of benefits from the current volume control compared to the
old
one:
- "default" input and output control
- microphone level checks
- sound effects level control
- per-application volume control (for apps that support it)
Yes, these are neat. Especially default input device control. And that's
more support for the "ship two mixers" compromise (which, ironically, it
turns out is exactly what we've been doing for three releases). These
are great features of PulseAudio (supplied up till now by pavucontrol).
I like them. I've written blog entries extolling their virtues. I've
cited them in long argumentative threads about how PA is shit. But they
don't excuse you from covering really basic audio use cases like
*digital frickin' output*.
The only use case(s) that we haven't catered for are for people
who want
to record things, and the sound card has more than 1 input.
No, not correct at all. You haven't yet catered for people who want to
*monitor* (rather than record) an input channel, people who have digital
outputs, or people who have analog surround sound setups (the Logitech
Z-5300 has been in production for about seven years for a *reason* -
people buy this stuff).
Yes, it's a
big omission, but that doesn't mean you're allowed to write off the
benefits we're bringing for a large number of users already.
I'm not. As I said, I like those things. Which I was I was on the side
which was supporting the compromise by which we would have those
features AND the features g-v-c is missing. It's not frickin' rocket
science!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:44 a.m.
Adam,
On Sat, May 2, 2009 at 9:59 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Sun, 2009-05-03 at 01:59 +0100, Bastien Nocera wrote:
> > Here's the other thing that gets me about this: okay, so you thought
> > about the use cases you want to support and came up with a design.
> > Great.
> >
> > But we don't even have that design yet. That design includes input
> > switching and profile switching.
>
> Tell me where I wrote that:
> https://fedoraproject.org/wiki/Features/VolumeControl#User_Experience
>
> <snip rant>
>
> *Where*
>
> I already asked this question when Will made the same assumption as you
> did, during the Fesco meeting. The use cases we had didn't include any
> need for profile switching.
That just makes me question even more your competence to be doing the
design; if you manage to come up with a design for a mixer application
without considering the importance of digital output, well. Er.
That's...um. My output device is connected digitally. So are zillions of
others. That's why soundcards ship with S/PDIF outputs. Even cheap
crappy onboard sound, where the manufacturers would gladly save a cent
any old way, universally include S/PDIF now - because people want it.
How were you expecting us to hear any sound?
This is getting crazy. You are questioning Bastien's interface design
competence. Pretty bold statement from someone, I suspect, many of us
have never heard of before.
Your rhetorical style isn't really helping here either. Would be nice
if you stopped throwing around meaningless statistics (zillions) and
gave us some credit for actually knowing what the hell we are doing.
If only to give the impression that you know what the hell you are
doing.
I suspect this whole process was managed by people who are great at
interface design, and great at the software side of audio/video (which I
know you are), but perhaps didn't think hard enough about what people
actually do with audio hardware.
And your suspicion is wrong. We've discussed these things many times.
We've even had pretty heated discussions about it ourselves.
However, in order to move forward, we need to make choices.
Inevitably, we will not please everyone.
...
> Yes, it's a
> big omission, but that doesn't mean you're allowed to write off the
> benefits we're bringing for a large number of users already.
I'm not. As I said, I like those things. Which I was I was on the side
which was supporting the compromise by which we would have those
features AND the features g-v-c is missing. It's not frickin' rocket
science!
Please read my first post again:
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02534.html
It is just not as simple as you make it out to be. A great product is
not a list of features. It must be designed. When we use a
time-based release process we will NEVER have a perfect or great
Fedora release. It just can't happen. Fedora is the vanguard. It is
the continual forward motion of our designs (mostly upstream ones).
We are *different* from Ubuntu and where you used to work.[1] We
differentiate ourselves by having an uncompromising position on
freedom and design. We don't ship non-free codecs even though (as you
say) zillions of people need them. We ship the best of breed software
and software that represents the right way forward even when it isn't
yet perfect. There are many technical reasons why we do this and why
it is good for us, upstreams, and informing/educating/engaging our
users.
But the principle reason is that it is the Fedora brand.
Jon
[1] Also since we are not creating a product where Ubuntu and Mandriva
are. And if we want to change this there is a heck of a lot of work
to do.
12:12 p.m.
On Sun, 2009-05-03 at 12:44 -0400, William Jon McCann wrote:
>> I already asked this question when Will made the same
assumption as you
>> did, during the Fesco meeting. The use cases we had didn't include any
>> need for profile switching.
>
> That just makes me question even more your competence to be doing the
> design; if you manage to come up with a design for a mixer application
> without considering the importance of digital output, well. Er.
> That's...um. My output device is connected digitally. So are zillions of
> others. That's why soundcards ship with S/PDIF outputs. Even cheap
> crappy onboard sound, where the manufacturers would gladly save a cent
> any old way, universally include S/PDIF now - because people want it.
> How were you expecting us to hear any sound?
This is getting crazy. You are questioning Bastien's interface design
competence. Pretty bold statement from someone, I suspect, many of us
have never heard of before.
Sorry, not exactly - in fact I said "I suspect this whole process was
managed by people who are great at interface design..."
The problem is that it seems Bastien didn't think too hard about what
use cases the design would need to cover, in terms of actual uses of
actual hardware. Note that this is not the same as attacking the
interface design per se. The design is fine for the use cases it covers.
The problem is it doesn't cover all of the use cases it needs to.
Whether you've heard of me before or not ought to be irrelevant. The
point should be whether what I say is valid or not.
Your rhetorical style isn't really helping here either. Would be
nice
if you stopped throwing around meaningless statistics (zillions) and
gave us some credit for actually knowing what the hell we are doing.
If only to give the impression that you know what the hell you are
doing.
It's hard to give you credit for knowing what the hell you're doing when
your actions don't substantiate it. Designing a mixer application with
no regards for any use case more advanced than "analog stereo output" is
not a great way to indicate that you know what you're doing.
> I suspect this whole process was managed by people who are great
at
> interface design, and great at the software side of audio/video (which I
> know you are), but perhaps didn't think hard enough about what people
> actually do with audio hardware.
And your suspicion is wrong. We've discussed these things many times.
We've even had pretty heated discussions about it ourselves.
However, in order to move forward, we need to make choices.
Inevitably, we will not please everyone.
I just cannot for the life of me see how you could possibly think that
making it impossible to enable digital or analog surround output is a
sensible choice. And it seems you now agree, since profile switching is
planned for a future g-v-c release. Ditto with input switching. So did
you get it wrong at first or are you getting it wrong now?
...
>> Yes, it's a
>> big omission, but that doesn't mean you're allowed to write off the
>> benefits we're bringing for a large number of users already.
>
> I'm not. As I said, I like those things. Which I was I was on the side
> which was supporting the compromise by which we would have those
> features AND the features g-v-c is missing. It's not frickin' rocket
> science!
Please read my first post again:
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02534.html
It is just not as simple as you make it out to be. A great product is
not a list of features. It must be designed. When we use a
time-based release process we will NEVER have a perfect or great
Fedora release. It just can't happen. Fedora is the vanguard. It is
the continual forward motion of our designs (mostly upstream ones).
We are *different* from Ubuntu and where you used to work.[1]
I've never worked for Ubuntu. (No-one works for Ubuntu, in fact, people
work for Canonical. But I've never worked for them either. I worked for
Mandriva.)
I find it surprising that you say we'll never have a great Fedora
release. That's a bit sad. Perfect? Of course not. But if everyone
agreed that we'd never have a great Fedora release, I'd wonder what the
hell I was wasting my time on. I hope yours is a minority position.
We
differentiate ourselves by having an uncompromising position on
freedom and design. We don't ship non-free codecs even though (as you
say) zillions of people need them. We ship the best of breed software
and software that represents the right way forward even when it isn't
yet perfect. There are many technical reasons why we do this and why
it is good for us, upstreams, and informing/educating/engaging our
users.
I know all this rhetoric. It does not apply to the issue at hand. We do
not need to ship a prototype design with half the features missing as
our default (and only!) mixer in order effectively to work on it.
Honestly I doubt it would even need to be *packaged*, as I doubt the
people who are working on it would use the packaged code, and you seem -
to say the least - resistant to any kind of external input on how it
should work. But it would be perfectly easy for it to be packaged and
available without it being the sole graphical mixer available by default
for people who just want to get sound out of their systems - including
developers of all sorts of other components and people who contribute to
Fedora in other ways, not just 'Joe Users'. Many of the people who have
gone on record as stating that they were negatively affected by the new
mixer are Fedora developers and contributors.
Yes, we "ship the best of breed software and software that represents
the right way forward even when it isn't yet perfect". But there's a
balance, here, and you're fooling yourself if you think there isn't. If
that were all there was to the story, Fedora stable releases wouldn't
exist, and everyone would use Rawhide. After all, that's the code that
represents the right way forward even if it isn't yet perfect. Hell,
we'd be running something rawer than Rawhide. But that isn't the case.
We don't update the kernel every 24 hours to the last code someone
kicked into git, we don't update GNOME every 24 hours with the latest
code from SVN (or git, now), we don't ship stable releases in this
state, we actually *ship stable releases* (and many of our developers
use them). Why? Because even developers need a base of reasonably usable
code in all the bits they're *not* working on. This applies to volume
control applications as much as to anything else. Your wonderful new
volume control application design is *not finished* and is, apparently
by general admission at this point, the source of major functional
regressions for perfectly smart people including Fedora hackers. Please
either let us ship something alongside it that provides the important
functionality that it is missing, or hold off on shipping it until it's
done. That's all that's being asked here.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:19 p.m.
On Sun, 2009-05-03 at 10:12 -0700, Adam Williamson wrote:
> We are *different* from Ubuntu and where you used to work.[1]
I've never worked for Ubuntu. (No-one works for Ubuntu, in fact, people
work for Canonical. But I've never worked for them either. I worked for
Mandriva.)
Sorry, just realized I missed the "and" in that sentence. Disregard this
bit, then.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:52 p.m.
On Sun, 2009-05-03 at 10:12 -0700, Adam Williamson wrote:
The problem is that it seems Bastien didn't think too hard about what
use cases the design would need to cover, in terms of actual uses of
actual hardware. Note that this is not the same as attacking the
interface design per se. The design is fine for the use cases it
covers.
The problem is it doesn't cover all of the use cases it needs to.
The use cases were there for people to read for *1 frickin' year*. It
went through Fesco's approval. You would have thought *someone* *anyone*
would have seen that use cases were missing.
You didn't, I didn't, people tried to close the door after the horse had
bolted.
2:10 p.m.
On Sun, May 03, 2009 at 07:52:02PM +0100, Bastien Nocera wrote:
The use cases were there for people to read for *1 frickin'
year*. It
went through Fesco's approval. You would have thought *someone* *anyone*
would have seen that use cases were missing.
You mean the "User Experience" section of Features/VolumeControl is
supposed to be *exhaustive*? Is that the standard way features are to
be described? Did FESCO know?
OG.
2:13 p.m.
On Sun, 2009-05-03 at 19:52 +0100, Bastien Nocera wrote:
On Sun, 2009-05-03 at 10:12 -0700, Adam Williamson wrote:
>
> The problem is that it seems Bastien didn't think too hard about what
> use cases the design would need to cover, in terms of actual uses of
> actual hardware. Note that this is not the same as attacking the
> interface design per se. The design is fine for the use cases it
> covers.
> The problem is it doesn't cover all of the use cases it needs to.
The use cases were there for people to read for *1 frickin' year*. It
went through Fesco's approval. You would have thought *someone* *anyone*
would have seen that use cases were missing.
You keep falling back on the feature page.
Sorry, it's kind of hard to test something that doesn't exist. I don't
understand why you seem to be having so much trouble understanding that.
You didn't, I didn't, people tried to close the door after
the horse had
bolted.
Wide testing isn't going to happen until at least the release of Beta.
That's why it's called Beta.
This "Oh, you didn't complain a year ago you're too late" thing is a
cop-out.
2 p.m.
On Sat, 2009-05-02 at 18:59 -0700, Adam Williamson wrote:
On Sun, 2009-05-03 at 01:59 +0100, Bastien Nocera wrote:
> > Here's the other thing that gets me about this: okay, so you thought
> > about the use cases you want to support and came up with a design.
> > Great.
> >
> > But we don't even have that design yet. That design includes input
> > switching and profile switching.
>
> Tell me where I wrote that:
> https://fedoraproject.org/wiki/Features/VolumeControl#User_Experience
>
> <snip rant>
>
> *Where*
>
> I already asked this question when Will made the same assumption as you
> did, during the Fesco meeting. The use cases we had didn't include any
> need for profile switching.
That just makes me question even more your competence to be doing the
design; if you manage to come up with a design for a mixer application
without considering the importance of digital output, well. Er.
That's...um. My output device is connected digitally. So are zillions of
others. That's why soundcards ship with S/PDIF outputs. Even cheap
crappy onboard sound, where the manufacturers would gladly save a cent
any old way, universally include S/PDIF now - because people want it.
How were you expecting us to hear any sound?
I suspect this whole process was managed by people who are great at
interface design, and great at the software side of audio/video (which I
know you are), but perhaps didn't think hard enough about what people
actually do with audio hardware.
I call BS here. PulseAudio never supported SPDIF outputs properly
before. So we really haven't made the experience any worse.
<snip>
> A couple of benefits from the current volume control compared to
the old
> one:
> - "default" input and output control
> - microphone level checks
> - sound effects level control
> - per-application volume control (for apps that support it)
Yes, these are neat. Especially default input device control. And that's
more support for the "ship two mixers" compromise (which, ironically, it
turns out is exactly what we've been doing for three releases). These
are great features of PulseAudio (supplied up till now by pavucontrol).
I like them. I've written blog entries extolling their virtues. I've
cited them in long argumentative threads about how PA is shit. But they
don't excuse you from covering really basic audio use cases like
*digital frickin' output*.
> The only use case(s) that we haven't catered for are for
people who want
> to record things, and the sound card has more than 1 input.
No, not correct at all. You haven't yet catered for people who want to
*monitor* (rather than record) an input channel
What on earth is "monitoring" an input? There's a volume level in
gnome-volume-control, we didn't have that before. I stand by the
statement I made above. If I didn't understand the problem properly,
feel free to hop onto the fedora-desktop list and explain what's missing
from:
http://fedoraproject.org/wiki/Features/VolumeControlContinued
, people who have digital
outputs, or people who have analog surround sound setups (the Logitech
Z-5300 has been in production for about seven years for a *reason* -
people buy this stuff).
Analog surround will be supported by the next version of
gnome-volume-control. You had to poke in ALSA to get this working
before, now you can use pavucontrol, or a one-liner in pacmd to fix
that.
Not a regression then.
> Yes, it's a
> big omission, but that doesn't mean you're allowed to write off the
> benefits we're bringing for a large number of users already.
I'm not. As I said, I like those things. Which I was I was on the side
which was supporting the compromise by which we would have those
features AND the features g-v-c is missing. It's not frickin' rocket
science!
Seriously. The discussion started because there were regressions, then
you go on accusing us of missing features that were never properly
supported in the first place.
SPDIF and analog surround weren't supported by the crappy mixers we had
before, and they're not supported now. But now we have the framework to
make those work. I see that as a great step forward.
2:37 p.m.
On Sun, 2009-05-03 at 20:00 +0100, Bastien Nocera wrote:
> That just makes me question even more your competence to be
doing the
> design; if you manage to come up with a design for a mixer application
> without considering the importance of digital output, well. Er.
> That's...um. My output device is connected digitally. So are zillions of
> others. That's why soundcards ship with S/PDIF outputs. Even cheap
> crappy onboard sound, where the manufacturers would gladly save a cent
> any old way, universally include S/PDIF now - because people want it.
> How were you expecting us to hear any sound?
>
> I suspect this whole process was managed by people who are great at
> interface design, and great at the software side of audio/video (which I
> know you are), but perhaps didn't think hard enough about what people
> actually do with audio hardware.
I call BS here. PulseAudio never supported SPDIF outputs properly
before. So we really haven't made the experience any worse.
PulseAudio didn't before this cycle, no. I'm talking about regressions
compared to the tools included and easily accessible in F10 and previous
releases, not just in the Pulse features. I'll talk about this a bit
more further down.
> > The only use case(s) that we haven't catered for are
for people who want
> > to record things, and the sound card has more than 1 input.
>
> No, not correct at all. You haven't yet catered for people who want to
> *monitor* (rather than record) an input channel
What on earth is "monitoring" an input?
Just looping the sound from an input around to the output in real-time,
not recording from it. In implementation terms it's mostly the same as
input switching, but in *usage* terms it's a distinct case - take the
guy from this list who wants to listen to sound from an external device
via the line-in on his card.
There's a volume level in
gnome-volume-control, we didn't have that before. I stand by the
statement I made above. If I didn't understand the problem properly,
feel free to hop onto the fedora-desktop list and explain what's missing
from:
http://fedoraproject.org/wiki/Features/VolumeControlContinued
> , people who have digital
> outputs, or people who have analog surround sound setups (the Logitech
> Z-5300 has been in production for about seven years for a *reason* -
> people buy this stuff).
Analog surround will be supported by the next version of
gnome-volume-control. You had to poke in ALSA to get this working
before, now you can use pavucontrol, or a one-liner in pacmd to fix
that.
Not a regression then.
It is a regression, because in previous releases, we shipped an ALSA
mixer by default which *did* allow this functionality. Sure, it allowed
it with a really crappy interface, but it allowed it.
(Is this next version of g-v-c coming soon enough for us to shove it
into F11 at release? That would be nice.)
Your mention of pavucontrol seems to expose a bit of confusion, because
we have Lennart saying "pavucontrol should have been dropped from the
default install the minute the new g-v-c was pushed into Fedora. We
forgot to do that. We should do it now. End of story.", and William
saying "The fact that it is still currently in the menus is
almost certainly an oversight". So are you guys saying pavucontrol
should be installed by default, or not? Do you agree with Lennart and
William on this?
For now I'll act on the assumption that the counter-proposal is to drop
pavucontrol and ship only new g-v-c by default, since that seems to be
the majority position on your side. If that's the case, any
functionality provided by pavucontrol but not g-v-c is not important, as
it wouldn't be installed by default.
Seriously. The discussion started because there were regressions,
then
you go on accusing us of missing features that were never properly
supported in the first place.
SPDIF and analog surround weren't supported by the crappy mixers we had
before, and they're not supported now. But now we have the framework to
make those work. I see that as a great step forward.
This just isn't factually accurate.
Analog surround: on every card I've ever seen, this is how this is
implemented.
The card has the usual set of jacks - line / speaker out, line in, mic
in, maybe an aux in or something.
There is a switch-type mixer control which enables or disables analog
surround. When it's enabled, two of the jacks, which are usually line-in
and mic-in or something, instead become the extra outputs needed for
surround output: one for the rear speakers, one for the sub and the
center channel. When it's disabled, they have their original functions.
There's also (usually) some extra volume range-type elements which let
you control the volume of each of the parts of the surround system
separately, so you can compensate for how far away your surround
speakers or sub are to make sure the sound is balanced.
These elements are all exposed by ALSA, so any ALSA mixer - including
the old gnome-volume-control - can enable this functionality. Yes, it's
a crappy interface, but the function is available, and many people at
this point know how to use it. We shipped an ALSA mixer by default in
F10. The proposal of those opposed to the compromise approved by FESco
is not to ship one by default in F11 (and, as far as I can tell, not to
ship pavucontrol either). Hence, this feature was exposed by a graphical
application installed by default in F10, while under that proposal, it
will not be in F11. That is a regression.
Digital output: there are two main ways of implementing this.
Method 1: there is a switch-type ALSA mixer element which enables or
disables digital output (usually labelled IEC958 Output or something
similar). Hence any ALSA mixer allows you to enable or disable digital
output. As discussed above, this would therefore be available in F10,
not in F11: hence, regression.
Method 2: the digital output is implemented as a separate playback
'interface' (sorry, I don't know the correct technical term for it) by
ALSA, so to output to it, you have to do something like 'mplayer -ao
alsa:device=spdif', or create a little ~/.asoundrc file that sets up
this routing by default. Indeed there was no GUI way to do this in F10,
so the implementation of support for it via PA's profile system is an
improvement, and a really nice one (that I personally benefit from). So
there is no regression in this case.
FWIW, I believe Creative cards, which are likely the most popular
expansion cards, usually use the switch-type mixer element method. I'm
not sure which method Intel onboard hardware, which is probably the most
common type of sound hardware taken all-in-all, use.
So, summary: in two out of three of the cases for analog surround output
and digital output, the anti-FESco-compromise position results in a
regression from functionality exposed via a GUI tool installed by
default in F10. In one case, it results in no benefit, because g-v-c
doesn't support profiles yet and they apparently don't want to ship
pavucontrol any more.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:56 a.m.
On Sun, 03.05.09 12:37, Adam Williamson (awilliam(a)redhat.com) wrote:
On Sun, 2009-05-03 at 20:00 +0100, Bastien Nocera wrote:
> > That just makes me question even more your competence to be doing the
> > design; if you manage to come up with a design for a mixer application
> > without considering the importance of digital output, well. Er.
> > That's...um. My output device is connected digitally. So are zillions of
> > others. That's why soundcards ship with S/PDIF outputs. Even cheap
> > crappy onboard sound, where the manufacturers would gladly save a cent
> > any old way, universally include S/PDIF now - because people want it.
> > How were you expecting us to hear any sound?
> >
> > I suspect this whole process was managed by people who are great at
> > interface design, and great at the software side of audio/video (which I
> > know you are), but perhaps didn't think hard enough about what people
> > actually do with audio hardware.
>
> I call BS here. PulseAudio never supported SPDIF outputs properly
> before. So we really haven't made the experience any worse.
PulseAudio didn't before this cycle, no. I'm talking about regressions
compared to the tools included and easily accessible in F10 and previous
releases, not just in the Pulse features. I'll talk about this a bit
more further down.
There are no regressions in comparison to the the SPDIF status quo
ante. Accessing iec985:xxx was previously available and basically still is.
> SPDIF and analog surround weren't supported by the crappy
mixers we had
> before, and they're not supported now. But now we have the framework to
> make those work. I see that as a great step forward.
This just isn't factually accurate.
Analog surround: on every card I've ever seen, this is how this is
implemented.
Analog surround support in ALSA mixer has been completely broken since
time began and still is. I cannot tape over that fact in PA.
When used for surround sound the ALSA mixer knows channels such as
"Rear Front Left" and "Side Front Left". That is broken. The ALSA
mixer *never* worked for surround sound volume control and still
doesn't. PA synthesizes software volume control when doing surround
playback which is currently the best option we have, and works even if
it is not optimal. And certainly is better then the status quo ante.
There is a switch-type mixer control which enables or disables
analog
surround. When it's enabled, two of the jacks, which are usually line-in
and mic-in or something, instead become the extra outputs needed for
surround output: one for the rear speakers, one for the sub and the
center channel. When it's disabled, they have their original
functions.
ALSA should switch the necessary controls when we open the
"surround51:" devices and suchlike. If it doesn't switch those
controls then please file a bug against ALSA.
There's also (usually) some extra volume range-type elements
which let
you control the volume of each of the parts of the surround system
separately, so you can compensate for how far away your surround
speakers or sub are to make sure the sound is balanced.
Nice idea. Completely broken, as mentioned above.
These elements are all exposed by ALSA, so any ALSA mixer -
including
the old gnome-volume-control - can enable this functionality. Yes, it's
a crappy interface, but the function is available, and many people
at
No. It's not available. The ALSA mixer is completely broken for
surround sound.
Digital output: there are two main ways of implementing this.
Method 1: there is a switch-type ALSA mixer element which enables or
disables digital output (usually labelled IEC958 Output or something
similar). Hence any ALSA mixer allows you to enable or disable digital
output. As discussed above, this would therefore be available in F10,
not in F11: hence, regression.
Nah. using this is a misuse. You always should access SPDIF via the
'iec985' device, which is what PA does. It will switch the appropriate
controls automatically and lock them and switch them back after use.
The fact that these controls are available is an implementation detail
which should be and is hidden by PA.
aethod 2: the digital output is implemented as a separate playback
'interface' (sorry, I don't know the correct technical term for it) by
ALSA, so to output to it, you have to do something like 'mplayer -ao
alsa:device=spdif', or create a little ~/.asoundrc file that sets up
this routing by default. Indeed there was no GUI way to do this in F10,
so the implementation of support for it via PA's profile system is an
improvement, and a really nice one (that I personally benefit from). So
there is no regression in this case.
This distinction is nonsense.
It's the same as method 1. All sound cards have controls to configure
a few spdif settings and as long as you access the device via
"iec985:" alsa should configure everything as necessary.
So, summary: in two out of three of the cases for analog surround
output
and digital output, the anti-FESco-compromise position results in a
regression from functionality exposed via a GUI tool installed by
default in F10. In one case, it results in no benefit, because g-v-c
doesn't support profiles yet and they apparently don't want to ship
pavucontrol any more.
This is wrong. PA handles spdif correctly. There is not
regression. And PA handles the surround mixer situation better than
the raw ALSA mixer. There is no regression.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:29 a.m.
On Mon, 2009-05-04 at 14:56 +0200, Lennart Poettering wrote:
time began and still is. I cannot tape over that fact in PA.
...
Nah. using this is a misuse. You always should access SPDIF via the
'iec985' device, which is what PA does. It will switch the appropriate
...
This is wrong. PA handles spdif correctly. There is not
regression. And PA handles the surround mixer situation better than
the raw ALSA mixer. There is no regression.
Lennart - I'm not talking about PA. I've already said the way PA does
analog surround and S/PDIF, with its profile support, is a great
improvement. I like it. But the current counter-proposal for F11 is to
ship gnome-volume-control and no other mixer by default. g-v-c does not
expose PA's profile support. So no matter how great PA is - by this
proposal, we would *not be exposing* all that greatness by default in
F11 at all. People would somehow have to figure out to install
pavucontrol before they could get to that greatness.
The question is g-v-c vs. legacy mixer, not PulseAudio per se.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:36 p.m.
Lennart Poettering wrote:
When used for surround sound the ALSA mixer knows channels such as
"Rear Front Left" and "Side Front Left". That is broken.
It may seem broken for you, and the interface is certainly suboptimal, but
it's better than not being able to control the surround balance at all. For
users, the current interface WORKS.
Nah. using this is a misuse. You always should access SPDIF via the
'iec985' device, which is what PA does. It will switch the appropriate
controls automatically and lock them and switch them back after use.
The fact that these controls are available is an implementation detail
which should be and is hidden by PA.
But until that works and is exposed in the relevant UIs, toggling the
boolean switch WORKS.
You can argue that the interface is crap, and I actually agree with you
there, but not that it's not there (it is).
Kevin Kofler
3:21 p.m.
On Mon, 04.05.09 21:36, Kevin Kofler (kevin.kofler(a)chello.at) wrote:
Lennart Poettering wrote:
> When used for surround sound the ALSA mixer knows channels such as
> "Rear Front Left" and "Side Front Left". That is broken.
It may seem broken for you, and the interface is certainly suboptimal, but
it's better than not being able to control the surround balance at all. For
users, the current interface WORKS.
Only if in your vocabulary "works" means "I know all bugs and can work
around them". Otherwise surround mixing in ALSA does not qualify as
"works" I would say.
> The fact that these controls are available is an implementation
detail
> which should be and is hidden by PA.
But until that works and is exposed in the relevant UIs, toggling the
boolean switch WORKS.
That may work because you are lucky. Controlling digital out via the
manually fiddling with the direct mixer controls is not how things are
supposed to work in ALSA. You are supposed to use "iec958" as device
string when doing SPDIF. Doing it by directly controlling the mixer
like you can do on some cards always has been a dirty hack (an
uncessary one even!) and hence the fact that this is now hidden should
not be considered a regression in any way.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:38 a.m.
William Jon McCann wrote:
...
But frankly, at this point you're out-emailing the rest of us
and
we're not going to be able to compete on these terms.
*maniacal laugh*
Yes, he's had the patience to reply to all the arguments presented, to
which the response is ...
"Come on Tonto, we're outnumbered. Oh, and they're faster than we are."
10:42 a.m.
On Fri, 01.05.09 10:32, David Woodhouse (dwmw2(a)infradead.org) wrote:
There seemed to be a policy of closing bugs WONTFIX and telling
people
that their use case, which used to work in F-10 and now doesn't, is not
appropriate for Fedora. That seems to include my own report of "I want
to be able to turn my volume up past 80%", as far as I can tell.
Please refer to actual bug reports when you express baseless
accusations like this.
Also, please stop your ugly demagogy. You use expressions like "not
appropriate for Fedora" while it is clear that your exotic use cases
have been thought as "inappropriate for the default installed tool"
only. There is quite a distinction between "appropriate for Fedora"
and "appropriate for the default installed tool". And you know
that.
I think this mail of mine still summarizes perfectly how exotic your
three use cases are (at the end):
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02153.html
But of course, you didn't respond to that mail...
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:47 a.m.
Okay, first, since you're "one of those people"... /Please do not quote
my e-mail address unobfuscated in message bodies./ Now that that's out
of the way...
Lennart Poettering wrote:
I think this mail of mine still summarizes perfectly how exotic your
three use cases are (at the end):
https://www.redhat.com/archives/fedora-devel-list/2009-April/msg02153.html
But of course, you didn't respond to that mail...
...but I did[1] (not to that specific mail, but to the assertion you
were making). I still maintain that using line-in to connect a second
device to one set of speakers is *not* exotic (or at least, not nearly
as exotic as you clearly feel that it is).
1: http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/111401
--
Matthew
"Will somebody get this walking carpet out of my way?!"
-- Princess Leia Organa (Star Wars IV)
6:16 p.m.
On Thu, 2009-04-30 at 15:48 -0400, Bill Nottingham wrote:
Of course, I don't know that the proposed solution does this,
since,
a week after it was proposed, a week after we've cut our last milestone
release, and less than two weeks before we cut the hopefully-to-be-shipped
release candidate, this proposed solution *has yet to land in any form
at all*. Given the stage of the schedule now, I find it pretty preposterous
that we're still considering changing things.
So, to try and carry on being productive, here's the current status and
what needs to happen here. If people could *please* contribute to this
process that would be greatly appreciated.
There are two open review requests, one for gnome-alsamixer, one for
gst-mixer.
gnome-alsamixer: https://bugzilla.redhat.com/show_bug.cgi?id=497593
gst-mixer: https://bugzilla.redhat.com/show_bug.cgi?id=498136
we need to pick one and move ahead with it. The review needs to be done
and the package accepted into rawhide, then the change to add it to the
default spin can be done.
I did a quick review of both tools with Bill. Here's our conclusions.
gst-mixer - the old gnome-volume-control - has a rather better UI, but a
somewhat odd work flow. To select an input device you have to hit
Preferences and enable a bunch of controls "Line-in Capture", "CD
Capture", "Microphone Capture" etc. (It may that these are displayed by
default on some cards but this didn't work for me and Bill, I don't
really know). Then you can go to the Switches tab and select your input,
except for me the input selection switches act as checkboxes not radio
buttons (they should act as radio buttons and only let one be selected
at a time), so I can have Video Capture, Microphone Capture, CD Capture
and Line-in Capture selected all at once, but the one I clicked on last
is the one that's actually active.
So it's an odd interface and seems buggy for me and Bill, but it does
what you need in the end. I don't know if either of these things are
expected behaviour, Bastien might.
gnome-alsamixer - it's a butt-ugly UI. But then, it's just the same as
alsamixer and most other traditional mixers, it just shows you all the
channels and a bunch of checkboxes. It does some silly stuff like the
gradients on the sliders are the wrong way round, but that's not really
important. Fundamentally it works how most mixers classically do, and it
works properly for me: all my inputs have a "Rec." checkbox, and
checking the appropriate one selects that as the input channel, and they
act as radio buttons (even though they're displayed as checkboxes).
So, them's the choices. I don't really care which is picked, I'll
maintain either if wanted or hand off to someone else. Just according to
the FESco decision one needs to be picked and added ASAP.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:59 p.m.
On Thu, 2009-04-30 at 16:16 -0700, Adam Williamson wrote:
gst-mixer - the old gnome-volume-control - has a rather better UI,
but a
somewhat odd work flow. To select an input device you have to hit
Preferences and enable a bunch of controls "Line-in Capture", "CD
Capture", "Microphone Capture" etc. (It may that these are displayed by
default on some cards but this didn't work for me and Bill, I don't
really know). Then you can go to the Switches tab and select your input,
except for me the input selection switches act as checkboxes not radio
buttons (they should act as radio buttons and only let one be selected
at a time), so I can have Video Capture, Microphone Capture, CD Capture
and Line-in Capture selected all at once, but the one I clicked on last
is the one that's actually active.
So it's an odd interface and seems buggy for me and Bill, but it does
what you need in the end. I don't know if either of these things are
expected behaviour, Bastien might.
One strong thing gst-mixer has going for it is that it is what we had
before, so those people who were used to twiddling the bits, or use to
helping people through twiddling the bits will not have to learn yet
another new tool. To me, that seems the most appropriate thing here,
keep the old tool around long enough until we're comfortable with the
new tool to stand on its own.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:41 p.m.
Hi Spot,
On Thu, Apr 30, 2009 at 3:33 PM, Tom "spot" Callaway
<tcallawa(a)redhat.com> wrote:
On 04/30/2009 03:08 PM, William Jon McCann wrote:
> Look, calling our design the "Brave New World mixer" doesn't
> particularly make you come across as someone we should be listening
> to. And frankly, if you can't see why it is dumb to have two entries
> in the menu for controlling your sound and volume then well maybe we
> shouldn't be listening to you.
Remember kids, we probably shouldn't be listening to you. Red Hat
Desktop == Smart. You == Dumb.
Should have been obvious that I wasn't saying that. You should know better.
There is nothing about the current discussion that has anything to do
with good ideas only coming from Red Hat or the Desktop team. One of
the codesigners of this interface works for Canonical. The people who
we listen to are individuals who have proven themselves to be capable
(often through community contributions) or those who can express or
demonstrate new and interesting ideas. One of the problems with this
list in particular is that many of these people have been driven away.
I know this very well as someone who lurked on this list for many
years before being hired by Red Hat. The list was overwhelmed by
noise with a continuously decreasing amount of signal. Trust me,
there are people out there in the community who want to be part of the
process but want nothing to do with the bikeshedding and base level of
debate that often occurs here. Being able to clearly identify good
ideas and reject bad ones is important for community health.
Honestly, painting the debate as somehow us versus them is detrimental
to community health.
Thanks,
Jon
6:16 p.m.
On Thu, 2009-04-30 at 16:41 -0400, William Jon McCann wrote:
There is nothing about the current discussion that has anything to
do
with good ideas only coming from Red Hat or the Desktop team. One of
the codesigners of this interface works for Canonical.
As I noted a few days ago - Ubuntu 9.04 shipped with the old mixer.
gnome-volume-control-pulse is available as an alternative that installs
alongside the old mixer...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:48 p.m.
On Thu, Apr 30, 2009 at 03:33:28PM -0400, Tom spot Callaway wrote:
Remember kids, we probably shouldn't be listening to you. Red
Hat
Desktop == Smart. You == Dumb.
The problem with the desktop is that it's obvious, looks simple and
everyone has an opinion on it. But not all of these opinions are equally
valid. This kind of situation is much easier to deal with in, say, the
kernel VM system - in that case it would be perfectly acceptable for
people who spend their entire working lives concentrating on a specific
topic to say that they know better than people who occasionally touch
upon it.
The real question is whether we believe that the people who spend their
lives working on the Fedora desktop have a better understanding of the
issues than people who don't. I've disagreed with various decisions
they've made, and in some cases argued quite strongly. I've then often
discovered that they've done significantly more research than I have,
have carefully considered the issues that I thought were blindingly
obvious and have come to a conclusion based on the work that they've
done. In the majority of cases I've ended up agreeing with their
position. These aren't dictators who change software behaviour on a
whim. They're professionals who are doing their very best to make the
Fedora desktop a modern and usable system. And so it's entirely
unsurprising if they become upset at being told by a group of people who
*don't* work in that field that they're wrong, in the same way that I'd
end up pretty furious if FESCO overruled me on a power management issue
ten days after we passed final freeze.
It's not about smart versus dumb. If we trust these people then we have
to assume that in most cases they *will* know better than people who
argue against them on mailing lists. And if we don't trust them then
there's something pretty fundamentally wrong with the way we're
producing this distribution.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
7:53 p.m.
On Fri, 2009-05-01 at 00:48 +0100, Matthew Garrett wrote:
It's not about smart versus dumb. If we trust these people then
we
have
to assume that in most cases they *will* know better than people who
argue against them on mailing lists. And if we don't trust them then
there's something pretty fundamentally wrong with the way we're
producing this distribution.
I think the problem in this case is that they're considering the purity
of their system over the quality of the product of which it forms a
part.
The significant objection on the part of the desktop team is that it's
bad UI to have two volume controls as part of the desktop. i.e., they
have a policy that it's good UI to have one application per function,
this breaks that, therefore it's bad UI, therefore it's bad. There's a
perfectly good logic to their thought process.
The problem is it doesn't go far enough. It stops at "bad UI == bad",
but that isn't always true. I think everyone advocating this change
agrees that it's bad UI. It's never been presented as anything but a
stopgap measure. But the issue is that, in this case, the bad UI
produces a better *product*, in terms of an actual desktop operating
system which we are releasing very shortly.
The desktop team are thinking about their ongoing process of developing
a desktop, and from that point of view, suddenly throwing in a legacy
mixer application because they haven't quite finished twiddling the
problems out of the new one yet is nuts. Unfortunately, we're not
shipping an ongoing process of developing a desktop, we're shipping a
*point release of a desktop operating system*, with all the expectations
that are attached to that. Including the ability to perform really basic
configuration of sound devices from a graphical interface. if you look
at things from the context of the Fedora product, not from the
perspective of the GNOME design process, providing only the new
gnome-volume-control in Fedora 11 is a painfully obvious regression in
functionality.
This is clearly what our friends at Ubuntu think, given that quite late
in their release cycle, they dropped the new gnome-volume-control in
favour of gst-mixer *by default* (a much more invasive change than is
being proposed here). They made this change on March 3rd, 2009, and have
since shipped with it. I haven't seen any complaints about it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:56 p.m.
On Thu, Apr 30, 2009 at 05:53:48PM -0700, Adam Williamson wrote:
The problem is it doesn't go far enough. It stops at "bad UI
== bad",
but that isn't always true. I think everyone advocating this change
agrees that it's bad UI. It's never been presented as anything but a
stopgap measure. But the issue is that, in this case, the bad UI
produces a better *product*, in terms of an actual desktop operating
system which we are releasing very shortly.
Does it? The desktop team would presumably assert that the cost of the
reduced user experience and increased user confusion is sufficient to
make the product *worse* than it would without shipping two mixers.
There's no absolute truth here, so the question isn't which option is
worse. The question is who we trust to make that decision.
This is clearly what our friends at Ubuntu think, given that quite
late
in their release cycle, they dropped the new gnome-volume-control in
favour of gst-mixer *by default* (a much more invasive change than is
being proposed here). They made this change on March 3rd, 2009, and have
since shipped with it. I haven't seen any complaints about it.
Having been a part of the Ubuntu decision making process, I think using
Ubuntu as any sort of comparison here weakens the argument. We're
talking about the distribution that shipped compiz by default 18 months
ago, desite it clearly being a regression in a huge number of different
ways.
Having said that, there are ways in which the Ubuntu decision is a
better one than ours. It's less flying-car future, but there's no
regression and no additional user confusion. I've personally got no
objection to FESCO overruling a decision on technical grounds and
forcing a reversion to the previous status quo (or whatever else is
available under the contingency plans), but the compromise we've ended
up with here looks awfully like a baby that's been cut in half.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:16 p.m.
On Fri, 2009-05-01 at 02:56 +0100, Matthew Garrett wrote:
On Thu, Apr 30, 2009 at 05:53:48PM -0700, Adam Williamson wrote:
> The problem is it doesn't go far enough. It stops at "bad UI == bad",
> but that isn't always true. I think everyone advocating this change
> agrees that it's bad UI. It's never been presented as anything but a
> stopgap measure. But the issue is that, in this case, the bad UI
> produces a better *product*, in terms of an actual desktop operating
> system which we are releasing very shortly.
Does it? The desktop team would presumably assert that the cost of the
reduced user experience and increased user confusion is sufficient to
make the product *worse* than it would without shipping two mixers.
There's no absolute truth here, so the question isn't which option is
worse. The question is who we trust to make that decision.
Interestingly, I haven't seen anyone flat out make that assertion.
I don't see how it could possibly stand up, either. I mean, the
alternative they're arguing for is to stick with the current state: a
release note advising people to use alsamixer. So instead of having two
graphical interfaces, they're apparently happier to have one graphical
interface and one obscure and extremely user-unfriendly curses
interface. I really can't quite grok how that's better.
Believe me, alsamixer is user-unfriendly. I have several years of
experience of advising people to use it. I started out saying "oh, just
run alsamixer and do XYZ..." After aforesaid years of bitter experience,
I now say something like "run alsamixer. You might need to do alsamixer
-c0 or -c1 or -c2 or -c3, it depends how many cards you have. You can
scroll to the right by pressing the right arrow a lot of times to see
more controls, even though there's no scrollbar indicating this. You
toggle inputs on and off by pressing space, but you flip switches by
pressing m. To get to the capture inputs you either run alsamixer with
-Vcapture, or hit tab after running it."
I'm just at a loss to try and grok how this is considered preferable to
an alternative graphical mixer. Where's the win?
Having said that, there are ways in which the Ubuntu decision is a
better one than ours. It's less flying-car future, but there's no
regression and no additional user confusion. I've personally got no
objection to FESCO overruling a decision on technical grounds and
forcing a reversion to the previous status quo (or whatever else is
available under the contingency plans), but the compromise we've ended
up with here looks awfully like a baby that's been cut in half.
I don't really think so. We all seem to agree that the new mixer
interface is The Future and should suffice for most people, but not for
a significant minority. We want people using the new mixer interface to
make sure it's ready ASAP. So making it the default that most people
will encounter and be happy with, but having a relatively
easy-to-discover fallback for those whose needs aren't covered, seems
sensible to me. Given the choice between reverting to the old g-v-c by
default or this compromise, I'd probably choose the compromise.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:47 p.m.
On Thu, Apr 30, 2009 at 07:16:38PM -0700, Adam Williamson wrote:
On Fri, 2009-05-01 at 02:56 +0100, Matthew Garrett wrote:
> Does it? The desktop team would presumably assert that the cost of the
> reduced user experience and increased user confusion is sufficient to
> make the product *worse* than it would without shipping two mixers.
> There's no absolute truth here, so the question isn't which option is
> worse. The question is who we trust to make that decision.
Interestingly, I haven't seen anyone flat out make that assertion.
I don't see how it could possibly stand up, either. I mean, the
alternative they're arguing for is to stick with the current state: a
release note advising people to use alsamixer. So instead of having two
graphical interfaces, they're apparently happier to have one graphical
interface and one obscure and extremely user-unfriendly curses
interface. I really can't quite grok how that's better.
The basic counterargument is that providing two mixers in the menu is a
cost to every user of Fedora. This cost is being justified on the basis
that the cost to some unknown number (but assumed to be a minority) of
Fedora users of *not* having that mixer is large. We have no numbers to
attach to any of these costs or the proportion of the user base
affected.
The people in the best position to make judgements about those costs are
the desktop team. They've got more experience in this field than you, me
or pretty much anyone else on this list. If they make an assertion about
these weightings then I'm not going to feel in a position to argue
against that until I've got some numbers, just as I'd be inclined to
ignore them completely if they started contradicting me on power
management issues without providing some numbers. Why do you feel
differently?
Believe me, alsamixer is user-unfriendly. I have several years of
experience of advising people to use it. I started out saying "oh, just
run alsamixer and do XYZ..." After aforesaid years of bitter experience,
I now say something like "run alsamixer. You might need to do alsamixer
-c0 or -c1 or -c2 or -c3, it depends how many cards you have. You can
scroll to the right by pressing the right arrow a lot of times to see
more controls, even though there's no scrollbar indicating this. You
toggle inputs on and off by pressing space, but you flip switches by
pressing m. To get to the capture inputs you either run alsamixer with
-Vcapture, or hit tab after running it."
I'm just at a loss to try and grok how this is considered preferable to
an alternative graphical mixer. Where's the win?
I don't think anyone's actually argued against there being a separate
graphical mixer. I think they've argued fairly strongly against it being
in the menu by default. But I think you're asking the wrong question.
The right question is "Who is going to need to run this program", and
the followup question is "And what kind of interface do *those people*
need?". If a large number of naive users need to run gst-mixer then
we've already failed badly. Adding it to a menu doesn't fix that. If the
users who need this functionality tend towards being advanced then the
nature of the UI is less important than the functionality is exposes.
> Having said that, there are ways in which the Ubuntu decision is
a
> better one than ours. It's less flying-car future, but there's no
> regression and no additional user confusion. I've personally got no
> objection to FESCO overruling a decision on technical grounds and
> forcing a reversion to the previous status quo (or whatever else is
> available under the contingency plans), but the compromise we've ended
> up with here looks awfully like a baby that's been cut in half.
I don't really think so. We all seem to agree that the new mixer
interface is The Future and should suffice for most people, but not for
a significant minority. We want people using the new mixer interface to
make sure it's ready ASAP. So making it the default that most people
will encounter and be happy with, but having a relatively
easy-to-discover fallback for those whose needs aren't covered, seems
sensible to me. Given the choice between reverting to the old g-v-c by
default or this compromise, I'd probably choose the compromise.
How is the user supposed to work out which is the fallback? Intuit it
from the fact that only one of the two seemingly equivalent choices in
the menu is started from the panel applet? How does the user work out
what the interaction between these two applications is? How do you
prevent the users who have a working pulseaudio setup from finding
gst-mixer and then breaking their systems? How do they recover once
they've done so?
My somewhat arrogant assertion here is that unless you've been asking
that sort of question then you don't understand all the issues involved
in this decision. And that implies that your opinion on the matter is
about as relevant as my opinion on QA workflows.
That doesn't mean that you have no input on the matter. Providing well
documented descriptions of failures or inadequacies in PA is helpful in
ensuring that it ends up as a better project that fills as many of the
needs of Fedora users as possible, but at some point you have to trust
that software maintainers know what they're doing. And if what you've
ended up with is something that the project as a whole doesn't find
useful, then the best thing to do is to avoid using it rather than
forcing UI changes upon an unwilling designer.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4:35 a.m.
On Fri, 2009-05-01 at 03:47 +0100, Matthew Garrett wrote:
The basic counterargument is that providing two mixers in the menu is
a
cost to every user of Fedora.
Having two mixers on the menu sucks, I agree. We should be able to
access the full ALSA mixer by pressing an 'advanced...' button in the
simplified mixer. Or something more well-hidden, perhaps.
But people were throwing their toys out of the pram and refusing to even
contemplate that kind of thing, so we ended up with the compromise. At
least the functionality is still there, even if it's buried in the
menus.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
9:32 p.m.
On Fri, 01.05.09 02:56, Matthew Garrett (mjg(a)redhat.com) wrote:
> This is clearly what our friends at Ubuntu think, given that
quite late
> in their release cycle, they dropped the new gnome-volume-control in
> favour of gst-mixer *by default* (a much more invasive change than is
> being proposed here). They made this change on March 3rd, 2009, and have
> since shipped with it. I haven't seen any complaints about it.
Having been a part of the Ubuntu decision making process, I think using
Ubuntu as any sort of comparison here weakens the argument. We're
talking about the distribution that shipped compiz by default 18 months
ago, desite it clearly being a regression in a huge number of different
ways.
Also, the comparison with Ubuntu stinks anyway. They had an earlier freeze
than we did. They were looking at an earlier version of the new
g-v-c. And the based their distro on PA 0.9.14, however the new g-v-c
is designed for 0.9.15 which was quite a big update.
After all, it's *we* who do the development. Both Bastien and I follow
the Fedora release cycle for our development. Since Ubuntu is not
doing any development in this area it is very likely that they'll
continue to be a few steps behind us unless they'd sync their releases
to the Fedora releases.
So all in all, comparing Ubuntu and Fedora here is comparing apples
and oranges.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:47 p.m.
On Fri, 2009-05-01 at 04:32 +0200, Lennart Poettering wrote:
Also, the comparison with Ubuntu stinks anyway. They had an earlier
freeze
than we did. They were looking at an earlier version of the new
g-v-c. And the based their distro on PA 0.9.14, however the new g-v-c
is designed for 0.9.15 which was quite a big update.
I don't want to push this as it was just a point made in passing, but I
think you're rather overstating the case there. Those aren't significant
differences: they were faced with the same choice between the same two
tools and considered the same issues we're considering. From the bug
report:
"what do you mean exactly there? why not using the new capplet in
jaunty? look at the list of bugs, the new capplet can't control alsa
directly or control other channel or enable numeric sources"
they didn't choose on the basis of some trivial issue that was fixed in
a newer g-v-c or pulseaudio; they chose because of the same issues we're
considering. The current g-v-c in Fedora can't do any of those three
things.
(btw, the digital output issue is an interesting one. Presumably the
PulseAudio folks will tell us that, if we want to switch from analog to
digital output, we should use pavucontrol, right? So what's that? Two
GUI applications to do the same thing...)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:38 p.m.
On Thu, 2009-04-30 at 19:47 -0700, Adam Williamson wrote:
(btw, the digital output issue is an interesting one. Presumably the
PulseAudio folks will tell us that, if we want to switch from analog
to
digital output, we should use pavucontrol, right? So what's that? Two
GUI applications to do the same thing...)
I rather want to amplify on this one, because I rather think I've hit a
winner. :)
what's pavucontrol?
to quote rpm -q pavucontrol:
"PulseAudio Volume Control (pavucontrol) is a simple GTK based volume
control tool ("mixer") for the PulseAudio sound server."
Why, it's a volume control tool! Isn't that exactly the same thing as
gnome-volume-control? Isn't the whole objection to including
gnome-alsamixer or gst-mixer that it's a terrible idea to install more
than one volume control tool by default?
Do we install pavucontrol by default? Why yes, yes we do.
http://cvs.fedoraproject.org/viewvc/comps/comps-f11.xml.in?revision=1.210...
there it is, right in the Sound and Video group, which is installed by
default in the desktop spin (and the desktop spin doesn't override it
out of there):
<packagereq type="default">pavucontrol</packagereq>
so why do we do this kind of interface insanity? Why would we install
*two* whole volume control applications for pulseaudio?
Why, because pavucontrol exposes useful functionality that
gnome-volume-control doesn't.
Here's Lennart helpfully explaining to me in the initial bug report -
491372 - that selecting between analog and digital output isn't a
problem, because PulseAudio handles it:
"Adam, you are misunderstanding how SPDIF in ALSA works. The special
device "spdif:" will toggle all mixer controls appropriately. It will
hence work properly an all cards -- and if it doesn't it's an ALSA bug.
Hence the profile logic PA exposes should provide *complete* SPDIF
experience -- fiddling with low level alsa mixer controls should never
be necessary."
Note that "the profile logic PA exposes" makes "fiddling with low level
alsa mixer controls" unnecessary. Great. But how is this profile logic
exposed? Does gnome-volume-control do it? Why no, no it doesn't. You
can't pick profiles with g-v-c.
But that's okay! No problem! You can do it with pavucontrol, and that's
installed by default!
Soooo - it's fine to have pavucontrol and gnome-volume-control installed
by default, because pavucontrol is an alternative graphical volume
control application that exposes useful functionality which is not
exposed by gnome-volume-control.
However, the suggestion that an alternative graphical volume control
application like gst-mixer or gnome-alsamixer should be installed by
default because it'd expose useful functionality which is not exposed by
gnome-volume-control is a terrible, terrible idea. It'll confuse people
to death, and it only covers corner cases!
Uhhh...okay.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:08 p.m.
On Thu, 2009-04-30 at 20:38 -0700, Adam Williamson wrote:
Do we install pavucontrol by default? Why yes, yes we do.
http://cvs.fedoraproject.org/viewvc/comps/comps-f11.xml.in?revision=1.210...
there it is, right in the Sound and Video group, which is installed by
default in the desktop spin (and the desktop spin doesn't override it
out of there):
I just checked, BTW - apparently we've been committing the UI error of
installing two volume control applications by default since Fedora 8.
pavucontrol is in the comps.xml file for F8, F9, and F10, along with
gnome-media, which contains gnome-volume-control. Presumably the
justification for this was that pavucontrol lets you control
Pulse-related stuff that the old gnome-volume-control didn't. So, it's
fine when Pulse wants to do it...
Looking at my F10 system, I can find PulseAudio Volume Control in Foot
menu / Sound & Video, while I find Volume Control in Foot menu /
System / Preferences / Hardware.
That's a nice clean UI, I suppose!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:43 a.m.
Adam Williamson wrote:
"Adam, you are misunderstanding how SPDIF in ALSA works. The
special
device "spdif:" will toggle all mixer controls appropriately. It will
hence work properly an all cards -- and if it doesn't it's an ALSA bug.
Hence the profile logic PA exposes should provide *complete* SPDIF
experience -- fiddling with low level alsa mixer controls should never
be necessary."
Which almost begs one to ask: what happens when there are two orthogonal
boolean controls involved? Four "profiles" to cover them?
10:21 a.m.
On Fri, 2009-05-01 at 13:43 +0100, Bill Crawford wrote:
Adam Williamson wrote:
> "Adam, you are misunderstanding how SPDIF in ALSA works. The special
> device "spdif:" will toggle all mixer controls appropriately. It will
> hence work properly an all cards -- and if it doesn't it's an ALSA bug.
> Hence the profile logic PA exposes should provide *complete* SPDIF
> experience -- fiddling with low level alsa mixer controls should never
> be necessary."
Which almost begs one to ask: what happens when there are two orthogonal
boolean controls involved? Four "profiles" to cover them?
Run pavucontrol and have a look - most cards have a lot of profiles. I
have 15 on my internal card (covering many combinations of digital,
analog and 5.1 analog input / output), and six on my expansion card
(just digital / analog choices).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:07 p.m.
On Fri, 2009-05-01 at 00:48 +0100, Matthew Garrett wrote:
On Thu, Apr 30, 2009 at 03:33:28PM -0400, Tom spot Callaway wrote:
> Remember kids, we probably shouldn't be listening to you. Red Hat
> Desktop == Smart. You == Dumb.
The problem with the desktop is that it's obvious, looks simple and
everyone has an opinion on it. But not all of these opinions are equally
valid. This kind of situation is much easier to deal with in, say, the
kernel VM system - in that case it would be perfectly acceptable for
people who spend their entire working lives concentrating on a specific
topic to say that they know better than people who occasionally touch
upon it.
... And the kernel VM people tend to be able to back up their expertise
with hard data. If a patch isn't an improvement in some provable manner,
it doesn't get in to the kernel.
And the kernel has a pretty hard line stance on regressions. If a patch
causes regressions, it's ripped out immediately. No matter who wrote it.
We trust data, not experts.
It's not about smart versus dumb. If we trust these people then
we have
to assume that in most cases they *will* know better than people who
argue against them on mailing lists. And if we don't trust them then
there's something pretty fundamentally wrong with the way we're
producing this distribution.
Trust, but verify.
1:34 p.m.
On Sun, May 03, 2009 at 12:07:43PM -0500, Callum Lerwick wrote:
On Fri, 2009-05-01 at 00:48 +0100, Matthew Garrett wrote:
> The problem with the desktop is that it's obvious, looks simple and
> everyone has an opinion on it. But not all of these opinions are equally
> valid. This kind of situation is much easier to deal with in, say, the
> kernel VM system - in that case it would be perfectly acceptable for
> people who spend their entire working lives concentrating on a specific
> topic to say that they know better than people who occasionally touch
> upon it.
... And the kernel VM people tend to be able to back up their expertise
with hard data. If a patch isn't an improvement in some provable manner,
it doesn't get in to the kernel.
Like everything else, kernel VM performance is a tradeoff. Improvements
may benefit certain workloads while impairing others. It's rare for
changes to improve things for everybody - so the end result is a
judgement call, generally by the people who are assumed to know what
they're doing.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3 p.m.
On Sun, 2009-05-03 at 19:34 +0100, Matthew Garrett wrote:
On Sun, May 03, 2009 at 12:07:43PM -0500, Callum Lerwick wrote:
> On Fri, 2009-05-01 at 00:48 +0100, Matthew Garrett wrote:
> > The problem with the desktop is that it's obvious, looks simple and
> > everyone has an opinion on it. But not all of these opinions are equally
> > valid. This kind of situation is much easier to deal with in, say, the
> > kernel VM system - in that case it would be perfectly acceptable for
> > people who spend their entire working lives concentrating on a specific
> > topic to say that they know better than people who occasionally touch
> > upon it.
>
> ... And the kernel VM people tend to be able to back up their expertise
> with hard data. If a patch isn't an improvement in some provable manner,
> it doesn't get in to the kernel.
Like everything else, kernel VM performance is a tradeoff. Improvements
may benefit certain workloads while impairing others. It's rare for
changes to improve things for everybody - so the end result is a
judgement call, generally by the people who are assumed to know what
they're doing.
No, it is not a judgement call. Hard performance measurements are not
subjective.
We developers are not sheep, and this is not a closed proprietary
project. We expect our experts to show their work.
3:35 p.m.
On Sun, May 03, 2009 at 03:00:44PM -0500, Callum Lerwick wrote:
On Sun, 2009-05-03 at 19:34 +0100, Matthew Garrett wrote:
> Like everything else, kernel VM performance is a tradeoff. Improvements
> may benefit certain workloads while impairing others. It's rare for
> changes to improve things for everybody - so the end result is a
> judgement call, generally by the people who are assumed to know what
> they're doing.
No, it is not a judgement call. Hard performance measurements are not
subjective.
We developers are not sheep, and this is not a closed proprietary
project. We expect our experts to show their work.
Choosing the workloads that are important is a judgement call.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3:36 p.m.
On Thu, 2009-04-30 at 15:08 -0400, William Jon McCann wrote:
> Sorry, but I think you're picking entirely the wrong case to
try and
> make your point. Try as hard as I can, I can't see how it would be
> better to have the Brave New World mixer and a wiki page instructing
> people on how to use alsamixer than it is to have the Brave New World
> mixer and a second mixer application available in the menus. The total
> cost to the design of the desktop is: one additional menu entry. I'm
> really having a hard time seeing how this is a terrible design decision.
Look, calling our design the "Brave New World mixer" doesn't
particularly make you come across as someone we should be listening
to.
Sorry, that's not how I meant it. I like
referring to things with silly names (cf. Great Mixer Debate). It
doesn't *mean* anything. If you want to know what I think, read what I
say, and I've already said I like the new mixer design. I like
PulseAudio, I like what Lennart's doing to revise audio support, I've
been running the damn thing since it was called PolypAudio and I've been
doing user support trying to improve it for years. At this very moment I
am busy working on the tracker bug I filed with Lennart's help to try
and track down as many volume bugs as possible, which is one of the
things that needs to happen for the new mixer to be sufficient on its
own.
The typical problem of PulseAudio detractors is that they refuse to see
any value in PulseAudio and advocate disabling it at the first possible
opportunity, to everyone, for completely unrelated issues.
On the *other* side, the typical problem of some in PulseAudio / GNOME
is that they see enemies everywhere. I'm not an enemy. I'm not one of
the people who's just here to bash Pulse at every possible opportunity.
I'm trying to *help*, by removing what will otherwise become yet another
"PulseAudio sucks!" issue in Fedora 11. Do you really want that? Do you
*want* to release a Fedora 11 which gives more ammunition to the people
who just say that anything we try to do to improve the audio
infrastructure is broken? Can't we please just spike their guns so we
can get something fricking productive done?
And frankly, if you can't see why it is dumb to have two
entries
in the menu for controlling your sound and volume then well maybe we
shouldn't be listening to you.
Please instead of making personal attacks on me, explain. I *know* it's
not perfect UI, but perfect UI is not an almighty goal in and of itself,
it is a part of a product, and the goal of the product is to make people
happy by letting them do what they need to do. A 'good' UI which does
not let the user do what they need to do with it is no use. A 'bad' UI
which does is better. It's not perfect, but it's better.
Also, seems like a bad decision to
want to QA two entirely separate code paths for doing essentially the
same thing.
I never said it was perfect, I said it was an improvement on the current
situation. That does not require it not to have drawbacks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:27 p.m.
William Jon McCann wrote:
In this particular case, there is nothing wrong with telling some
people either:
a) you may have to wait *years* in order to get the optimal
experience.
b) The current release of this product is a fail! Go to this wiki page
and follow the instructions to make it work.
We simply cannot avoid this if we continue to use a
time-based release process. There will always be cases where we don't
finish everything we'd like to.
But it ok to ship a crappy or not ready product
as long as I created it.
That is, it cannot
if we ever want to recover marketshare and mindshare from other
distributions (not to mention other/better OS's),
"we" are not
competing with other distributions. That is just you
lennart and crew.
Here is a clue, making a better product will "recover" your precious
market and mind share. Telling people only you know what is best does not.
9:19 a.m.
On Thu, Apr 30, 2009 at 07:27:26PM -0400, TK009 wrote:
William Jon McCann wrote:
>
> In this particular case, there is nothing wrong with telling some
> people either:
a) you may have to wait *years* in order to get the optimal experience.
b) The current release of this product is a fail! Go to this wiki page
and follow the instructions to make it work.
> We simply cannot avoid this if we continue to use a
> time-based release process. There will always be cases where we don't
> finish everything we'd like to.
But it ok to ship a crappy or not ready product as long as I created it.
> That is, it cannot
> if we ever want to recover marketshare and mindshare from other
> distributions (not to mention other/better OS's),
"we" are not competing with other distributions. That is just you
lennart and crew.
Here is a clue, making a better product will "recover" your precious
market and mind share. Telling people only you know what is best does not.
We're finally reaching a point where dialogue between parties is
becoming more constructive and less vitriolic. Please don't reduce
the usefulness of the conversation.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
9:34 a.m.
Paul W. Frields wrote:
On Thu, Apr 30, 2009 at 07:27:26PM -0400, TK009 wrote:
> William Jon McCann wrote:
>
>> In this particular case, there is nothing wrong with telling some
>> people either:
>>
> a) you may have to wait *years* in order to get the optimal experience.
> b) The current release of this product is a fail! Go to this wiki page
> and follow the instructions to make it work.
>
>> We simply cannot avoid this if we continue to use a
>> time-based release process. There will always be cases where we don't
>> finish everything we'd like to.
>>
> But it ok to ship a crappy or not ready product as long as I created it.
>
>> That is, it cannot
>> if we ever want to recover marketshare and mindshare from other
>> distributions (not to mention other/better OS's),
>>
> "we" are not competing with other distributions. That is just you
> lennart and crew.
>
> Here is a clue, making a better product will "recover" your precious
> market and mind share. Telling people only you know what is best does not.
>
We're finally reaching a point where dialogue between parties is
becoming more constructive and less vitriolic. Please don't reduce
the usefulness of the conversation.
I respectfully disagree sir.
9:09 p.m.
On Fri, 2009-04-24 at 16:13 -0600, Kevin Fenzi wrote:
<snip>
== IRC LOG ==
Log posted at: https://fedoraproject.org/wiki/Meeting:FESCo-2009_04_24
"
<wwoods> Since it's come to this, I think we can say that the QA Team
recommendation is that the VolumeControl feature does *not* match its
original specification and should therefore be deferred to F12 *unless*
there's some other way provided cover the missing bits of functionality
- e.g. providing the old mixer UI somewhere in the menus.
"
The only thing that doesn't match on that page is this:
"
The multimedia experience of Fedora users is improved by an easily
understandable and much more flexible volume control model.
"
As it's improved, but not for all users.
5470
days inactive
5480
days old
153 comments
33 participants
participants (33)
-
"Jóhann B. Guðmundsson" -
Adam Williamson -
Bastien Nocera -
Bill Crawford -
Bill Nottingham -
Bruno Wolff III -
Callum Lerwick -
Chris Adams -
Christopher Aillon -
Chuck Anderson -
Clive Messer -
David Airlie -
David Woodhouse -
Denis Leroy -
drago01 -
Jesse Keating -
Josh Boyer -
Kevin Fenzi -
Kevin Kofler -
Lennart Poettering -
Mathieu Bridon -
Matthew Garrett -
Matthew Woehlke -
Matthias Clasen -
Olivier Galibert -
Paul W. Frields -
Rahul Sundaram -
Ralf Corsepius -
Seth Vidal -
TK009 -
Tom Callaway -
Toshio Kuratomi -
William Jon McCann