On 09/29/2011 02:11 AM, Alexandre Julliard wrote:
Vitaliy Margolenwine-devel@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