2008/6/12 Vitaliy Margolen wine-devel@kievinfo.com:
Reece Dunn wrote:
2008/6/11 Vitaliy Margolen wine-devel@kievinfo.com:
In short - that after everyone's hard work and 15 years of development wine-1.0 is just a release tag nothing more.
I think that this is overly harsh. It's like saying that you should not celebrate a birthday, as that is just you aging just a day, nothing more.
If birthdays would start coming every 2 weeks after about 100's you will loose track and won't care anymore which one it is.
But those releases are beta releases. The issue here is not that Wine does not have frequent releases - which it does - but that those releases are beta. The perception and reception is different. Just look at all the countless beta releases that Vista had and who was using them; the majority of users didn't start using it until release.
Wine is in a strange position as it is trying to make any Windows application (ultimately) run on any suitable posix system with a suitable X server. Given that a new version of Windows is usually released every 2-3 years, with new features, APIs and functionality,
I wouldn't go that far. Win2k was released in ... 2000. XP (which has some number of additions over win2k) was release in 2003 with minor additions in 2004 and 2005. And no one in their right mind makes Vista only versions. That gives us what? 8 years.
2007 (Vista) - 2002 (XP release) = 5 years, not 8. Vista was an exception to the release cycle that Microsoft had built since Win95. Windows 7 is scheduled for 2009, which makes that another 2 years. Excluding Vista, my statement holds.
No this argument don't fly - not much is changing in the win32api world, or MS would risk killing all their legacy stuff - which is the only reason windows is still being used.
I was told that MS has added thousands of new native APIs. There are the changes made to the theming code; the Desktop Window Manager (DWM) API; the new hyperlink control; the extension of buttons to support buttons with menus; the new file open/save API (which also has changes to the way the Win2K-style open/save dialogs are detected, I believe); the new enhanced message boxes; .... So saying that not much has changed in Win32 (and COM) is wrong.
Also, look at the Wine test results to see that a fair amount of the Win32 API have changed behaviour.
Yes, regressions will happen. Yes, applications will crash/fail to work. But think of all the applications that *do* work; given what
That's the problem. After identifying a regression it should be fixed. During the code freeze, the changes should be reverted, especially if this is new functionality that's having issues. And where were are with those? We have a big list of regressions introduced by major changes to different parts of Wine either right before the code freeze or during(!) the code freeze. And most of those regressions are still not dealt with.
So, like CodeWeavers, we need to pick a set of applications that we can say "Yes, these *will* work with 1.0." Other applications *may* work with 1.0 (and you'll need to look in the AppDB for your particular application), but if they regress it will not block the release of 1.0. Otherwise, you may as well not do a release, as the mountain is impossibly steep.
I'm not blaming anyone as I'm guilty creating regressions in the past. However the goal needs to shift from getting new features in, to stabilizing and bug fixing. And ~1 month for that is not enough, considering that it takes so long to fix some of the problems. I was really surprised to see _ANY_ new features getting into Wine in the last 2 months. Let alone major ones like XIM, child X windows, pixel formats.
So what new features have gone into RC1-4 (~2 months going on a 2 week release cycle)?
The major features you mentioned went in before the freeze, IIRC, so where is the problem? The regression that happened recently happened because of a fix introduced to fix a game. Yes, it broke other games (which I'd argue are good candidates for 1.0, so that particular commit should be reverted cleanly), but we need to figure out which games are important for 1.0. Another regression was the result of cleaning up deprecated alsa calls that broke older alsa drivers on various distributions (which I happened to spot - I thought it might have been the pulseaudio adapter, but my machine is currently using a real alsa driver).
Regressions happen. If they are in applications that we are going to support in 1.0, they should be fixed, otherwise they should be in the release notes if relevant
NOTE: I am not saying Wine is perfect, I'm saying that the message should be positive and realistic instead of unduly negative.
I did not meant to make it sound that negative. After all each new version of Wine had number of important features and loads of bug fixes. Which is great on it's own. Just don't make wine-1.0 anything more then it really is
- new release with bug fixes and no new features.
The point of the freeze is *not* to add any new features. The point is to address as many outstanding issues as possible, with minimal regression. Unless (and until) Wine has a full and complete implementation of the Windows API, then it does not stand a chance of running every application flawlessly. So the release needs to be pragmatic: which bugs are showstoppers, which applications does Wine need to run.
Does anyone know what the state of installing/running Office 2003 is, because I seem to recall there being a regression in this area. That is something that I would consider a blocker.
- Reece