wine has evolved too much in the recent years. and with the evolution new features have come. but unfortunately a program that tries to emulate a vast and complex system as windows are,has come to a point which it has flooded with bugs and "temp code". So the code freeze is a refreshing point which allows the programmers - contributors to polish their code so it can take more beati... implant more features. im hoping to see to even more bugs squeezed in rc2 and without wanting to stress you up dont forget that many eyes in the world of linux are watching you! my wish is to make wine a powerful tool will enable everyday users to able to use their favorite (win/mac) application at linux - break the compatibility factor!
stimpak wrote:> wine has evolved too much in the recent years. and with the evolution new features have come. > > but unfortunately a program that tries to emulate a vast and complex system as windows are,has come to a point which it has flooded with bugs and "temp code". > > So the code freeze is a refreshing point which allows the programmers - contributors to polish their code so it can take more beati... implant more features. > > im hoping to see to even more bugs squeezed in rc2 and without wanting to stress you up dont forget that many eyes in the world of linux are watching you! > > my wish is to make wine a powerful tool will enable everyday users to able to use their favorite (win/mac) application at linux - break the compatibility factor!Don't excpect anything spectacular out of Wine-1.0. It might run said list of programs without major issues. Other then that it will still be the same - mediocre - wide range of broken apps. Because they are just that - broken apps that shouldn't even run at all, but they do because windows coded to hide bugs.
Ok I will be a little more open on what to expect. Normal wine development is a mix of adding new features and regressions. Code freeze means regressions are being targeted. So this is great for people who applications did work and don't now. Yet 100 percent useless for those who programs need new features to work. Thing to expect from the code frease some applications that were plat a few versions back return to being plat again. Lot of niggling internal bugs to disappear. What not to expect tested applications that have never run in wine just to start working unless by extream luck that they were effected by those niggling bugs. There are going to be a few surprises of course. Really I would love to see a code freeze every 6 months just to mop out out standing regressions. So that once applications get to plat they stay that way.
On Sun, May 11, 2008 at 4:05 PM, oiaohm <wineforum-user at winehq.org> wrote:> Thing to expect from the code frease some applications that were plat a few versions back return to being plat again. Lot of niggling internal bugs to disappear. > > What not to expect tested applications that have never run in wine just to start working unless by extream luck that they were effected by those niggling bugs.Exactly. For ideas on how to help, btw, see http://wiki.winehq.org/PlatinumRegressionHunt> Really I would love to see a code freeze every 6 months > just to mop out out standing regressions. So that once applications > get to plat they stay that way.Sounds good to me; see http://wiki.winehq.org/TimeBasedReleases for a proposal along those lines. FWIW, automated application regression tests would help a lot with that "stay platinum" goal. - Dan
Ok it does not help programs where people have not done at least the min foot work for the application. Min foot work is having at least tested to what 2 versions of wine the fault happens between and that latest version is tested and still fails. ie like 0.9.60 and 0.9.61 as the two version no more than 1 version number apart. The test results in the appdb are useful. Now even better is if a person is prepared to take on a full regression hunt and find what patch causes its failure. http://wiki.winehq.org/RegressionTesting With the exact patch a really good bug report can be put in and a rollback patch created to keep application working until developers solve the issue. Working application comes down to how much user support we have for it too.
Seemingly Similar Threads
- [PATCH] x86/hvm: don't give vector callback higher priority than NMI/MCE
- [PATCH 0/8] enable endian checks for all sparse builds
- [PATCH 0/8] enable endian checks for all sparse builds
- [PATCH 0/6] map big page by platform IOMMU
- How to set the dimension of a matrix correctly?