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@xxxxxxxxxxxxx -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
