Friday, December 16, 2005, 11:26:28 PM, Scott Ritchie wrote:
On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote:
The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest?
If I may make a humble suggestion, it would be to time another stable (or semi-stable), regression-proofed release to roughly coincide with the various distributions freezing schedules. Ubuntu, for instance has an upstream version freeze on Jan 19th and a Feature Freeze on Feb 2nd. In my ideal world, we would have a Wine release just before that Jan 19th deadline, go into regression-fix and bughunt mode, and then have a release come out around Feb 2nd that had no regressions relative to 0.9 and the Jan 19th release.
That sounds to aggressive to me. We still a long ways away from major pieces falling into place. Most regressions you see, especially with games caused be major developments in d3d part of Wine. I don't think that will be "fixed" by then.
There are number of fixes being worked on for copy-protection systems. Some have to be tested over period of time to check for any regressions.
Looking at the bugzilla I can see that major effort is under way to have Picasa2 working. And we haven't seen a major flood of patches yet.
Also we are near the Christmas holidays which means everything will ground to a halt here soon. So basically we will have 2 weeks to wrap things up - too short of the time to get anything major out of the way.
IMHO before we can go into a code freeze we should put a status of all the major Wine parts together. To see what are we in the middle of doing. And decide what do we want to have in the next release. And what will have to wait.
Vitaliy.