scott at open-vote.org
Mon Sep 13 00:11:52 CDT 2010
On 09/12/2010 06:36 AM, Dan Kegel wrote:
> Looks like Alexandre must have fired up his time machine again :-)
> And as long as it's up and running, how about a look forward
> at the 1.4 release plans?
I've discussed this idea with a lot of (non-Wine-Developer)
stake-holders, and a few things came up pretty consistently.
1) Have some sort of time limit for the freeze process to start.
Specific features are great for a release, but recognize that Wine gets
dozens of features every month in the form of bug fixes and new
applications working. Add enough of them together and you have
something worthy of a release even without one big thing in particular.
2) That said, there are a few big things that would be great as release
goals in and of themselves. That means substantial effort to include
and polish them on behalf of core Wine developers, followed by a freeze.
Possible features to name here have already been listed by others and
in the wiki - DIB engine, Direct3D 10, OpenAL audio, etc.
3) Instead of a software developing perspective, we could instead
release based on a QA perspective. This would mean ignoring which
features were ready (or almost ready) and instead focus on the QA
metrics we have - make the test suite pass everywhere (and on Windows),
make sure we have some metric of test coverage, make sure the number of
nonworking apps hasn't increased in some time, and so on.
These ideas can all be combined, eg we don't freeze unless we have a big
feature OR a whole year has passed, and once we freeze we don't release
until the test suite passes on Windows, Linux, and Mac.
More information about the wine-devel