winecfg: Remove driver selection from Audio tab.

[Michael Stefaniuc]

Vitaliy Margolen wrote:
> On 09/27/2011 12:17 PM, Michael Stefaniuc wrote:
>> On 09/27/2011 03:20 AM, Vitaliy Margolen wrote:
>>> Could we please wait another week (until after the wineconf) before
>>> doing these whole sale changes?
>>>
>>> Please leave sound system and related winecfg code as-is.
>> Why?
>>
>> Come to think of it this would be the right time to do it:
>> - We are at the start of the commit period for 1.3.30
>> - People will be busy traveling to/from WineConf so a regression won't
>> halt their work.
>> - Andrew won't travel so he can fix regressions.
>> - We can directly motivate Andrew to fix those regressions "Oh,
>> regressions still open? No dinner for you tonight!".
> 
> Exactly because of all the regressions introduced with such a huge change.
> 
> I'm not a big fan of ripping things out and replacing them with new and
> shiny just because no one understands how it all needs to be done in the
New? mmdevapi was introduced with Vista a couple of years ago.
Shiny? For an 1:1 (feature wise) backend replacement? A backend that has
no UI component to it? Seriously?

> first place. It would be much better to see the entire conversion to
> mmdevapi in a separate tree stabilized before making it's way to main tree.
Like in a development tree? The Wine 1.3.x tree is a development tree.
Also how many people would you think would use that extra mmdevapi tree?
One? Two? So you'll get the same untested code merged at a later time.

> Wine is driven by wrong objectives. Most developers here don't give much
> rip about regressions if the code they've put in is "right". This is
Yes, sadly there are Wine developers that consider regressions they have
introduced "just normal bugs" which they will fix eventually if they are
interested. But there are a lot of other developers that fix the
regressions they have introduced with a hight priority. I venture to say
that most Wine developers prioritize regression bugs above normal bugs.

And no, Andrew's code is *NOT* "right" by any means! If we preferred the
"right" code we would have taken Maarten's code which nuked dsound out
of orbit. Andrew's code is a minimally invasive (for a big amount of
minimal) that replaces the winmm calls with mmdevapi. His patches didn't
even conflict with my COM cleanup and the COM implementation in dsound
is not only "wrong code" but also "bad and ugly".

> exactly the wrong way to do it. Don't take it from me, take it from the
> person who knows it much better and knows what he is talking about:
> http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/ba-p/440
> 
> 
> 
> "[T]he thing that really matters is the users of the code. The code
> itself is unimportant; the project is only as useful as people actually
> find it."
Exactly! And how did we care about our sound users all this years? By
ignoring all their bugs? There are 67 open dsound bugs, the oldest is
from 2004.

Again this is an 1:1 backend replacement with feature parity on the
"frontend". This is none of the stuff that Linus was targetting: "We
replace a 90% working solution with a 60% working solution, but you
don't need those 30% we took away", "We know it better", "You are not
our targeted audience". The programs that use dsound need to work
afterwards, period. Regressions are unavoidable but we do our very best
to fix those.

> You think that all people who'll find their program broken because of
> this sound rewrite care about the code? Or that now dsound talks to
> mmdevapi instead of winmm? Or remarks by Andrew that "he doesn't want to
Those people will stay on the old Wine version that worked for them
until we fix the regressions. On the other hand the people for which
dsound never worked will most likely appreciate that we are finally
working to fix their problem.

> fix old code because it's going away anyway. And he'd rather fix new
> code." a good excuse for their game to stop working on Wine?
Uh? Logic error... if he doesn't fixes the old code he cannot break it.
The new code on the other hand is new so he will fix the regressions in
that.

> I'd like you guys to think about what really is important users or code?
Users. But you seem to prefer the old code...

bye
	michael