Code freeze, or catching up with new features

stimpak · Post by **stimpak** » Fri May 09, 2008 2:40 pm

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!

vitamin · Post by **vitamin** » Fri May 09, 2008 2:44 pm

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.

James McKenzie · Post by **James McKenzie** » Sat May 10, 2008 8:22 pm

vitamin wrote:

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.

Then we need to 'break' Wine in the same ways. Just because the folks
at Microsoft decided to use 'hidden' code to get things to work right
does not mean that we have to take the high road and attempt to make
them fix it. We definitely need to fix code in Wine that is truely
temporary and to continue to add features that should work in a 1.0 release.

James McKenzie

David Gerard · Post by **David Gerard** » Sun May 11, 2008 3:41 pm

2008/5/11 James McKenzie <[email protected]>:

vitamin wrote:

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.

Then we need to 'break' Wine in the same ways. Just because the folks at
Microsoft decided to use 'hidden' code to get things to work right does not
mean that we have to take the high road and attempt to make them fix it. We
definitely need to fix code in Wine that is truely temporary and to continue
to add features that should work in a 1.0 release.

Yes. Unfortunately, app-specific tweaks are how Windows actually does
things - so you can't implement a fully compatible Win32 API without
doing the same. Appallingly inelegant and a disgusting offence against
all decent software engineering as it may be. (Because you could say
just that about Windows.)

At least it can wait until after 1.0. Get it working first, *then* break it.

(friendblaster.exe detected, file size and MD5 match? Report user's IP
to spamcop and cause their PC to catch fire.)

- d.

oiaohm · Post by **oiaohm** » Sun May 11, 2008 6:05 pm

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.

austin987 · Post by **austin987** » Sun May 11, 2008 6:46 pm

On Sun, May 11, 2008 at 6:05 PM, oiaohm <[email protected]> wrote:

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.

I don't know if the topic has been discussed, but that's a good idea
for the 1.2 branch, 1.4, etc. Do a code freeze, make sure our
guaranteed apps haven't hit any regressions, clear out any standing
regressions in non-guaranteed apps, release, and set a new higher
target.

Dan Kegel · Post by **Dan Kegel** » Sun May 11, 2008 7:07 pm

On Sun, May 11, 2008 at 4:05 PM, oiaohm <[email protected]> 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

hendrik · Post by **hendrik** » Sun May 11, 2008 9:53 pm

On Sun, May 11, 2008 at 06:05:11PM -0500, oiaohm wrote:

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.

Like TrueLove, for example, which used to work but no longer does.
http://appdb.winehq.org/objectManager.p ... n&iId=4050

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.

oiaohm · Post by **oiaohm** » Sun May 11, 2008 11:19 pm

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.