winecfg: Remove driver selection from Audio tab.
wine-devel at kievinfo.com
Wed Sep 28 08:09:01 CDT 2011
On 09/28/2011 05:31 AM, Michael Stefaniuc wrote:
> Vitaliy Margolen wrote:
>> On 09/27/2011 12:17 PM, Michael Stefaniuc wrote:
>> 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.
I'd expect most developers to test it it. Or at least those who interested
in the specific area. Some users, especially those who reported errors about
sound would be pointed to that tree as well. So it will get testing.
>> 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
My suggestion would be to revert those "fixes" unless said developers
willing to fix what they broke. Linus was pretty clear that he won't accept
patches from such developers. Complete 180 from Alexandre's view.
> 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.
Unfortunately no one goes back and fixes those other regressions. Many users
quit using Wine because of them. Not because of all other great stuff was
added to Wine.
> 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
More so reasons to have a separate tree to stabilize it before merging with
> Again this is an 1:1 backend replacement with feature parity on the
I think not! Andrew's biggest desire was to drop hardware acceleration
support. The only part that actually did work and produced best sound.
>> I'd like you guys to think about what really is important users or code?
> Users. But you seem to prefer the old code...
I prefer working code, regardless of it's age.
What I really like to see is stable Wine versions being released more often
if you think that the development tree is the right place to test nuclear
More information about the wine-devel