winecfg: Remove driver selection from Audio tab.

[Vitaliy Margolen]

On 09/29/2011 02:11 AM, Alexandre Julliard wrote:
> Vitaliy Margolen<wine-devel at kievinfo.com>  writes:
>
>> The part you forgot is Linux (referring to kernel here) being the most
>> successful FOSS project, used on super computers, stock exchanges,
>> banks, etc. While Wine still in it's perpetual alpha-beta state,
>> limited user base, and not recommended for production use.
>>
>> Not saying that AJ's ways are all that bad, but obviously not giving
>> the same results. Don't you think it's time to change things up a bit?
>
> So what do you suggest?
>
I can think of few things can be implemented right away and see how it goes:

1. Longer release cycle. Lets start with 3-4 weeks and extend if needed. 
Allow any new features first week of the release cycle only. Next two weeks 
are bug fixes and stabilization before release.

Or have same 2 week release cycle with every other release being release 
candidate and code freeze for the second 2 weeks to stabilize it.


2. All major changes (substantial code rewrites, new dlls (excluding stubs), 
core dll / server changes) should be submitted as a whole series. 
Alternatively available as an external tree. To not completely stop 
development of major features it should be ok for small trickle of changes 
like DIB which one by one replacing existing functionality. While still 
requiring same level of testing.

Such changes should have complete design proposal sent to wine-devel for 
discussions, preferably prior to codding. Don't need diagrams but at a 
minimum explanation what is the plan, how it supposed to work, what's wrong 
with current code that can't be fixed.

To not put all weight lifting on one person, person(s) most familiar with 
the area _have_ to review and approve before continuing. Even tho we don't 
have official maintainers, this might be the time to assign this responsibility.

Example of major changes: dsound rewrites, substantial d3d changes, 
wineserver/ntdll/kernel/user.


3. All regressions should be treated as blockers. And fixed before next 
release. If a regression is in some other area then patch introducing 
regression, no patches should be accepted from anyone else to the area in 
question until this regression is fixed. Or a work around found.


Of course this is just a suggested plan not set in stone. Just wanted to 
bring this up before Wineconf so people can think about it. Can continue the 
conversation there as well.

-Vitaliy