On 09/29/2011 02:11 AM, Alexandre Julliard wrote:
Vitaliy Margolen<wine-de...@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
