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