2008/5/5 Kai Blin kai.blin@gmail.com:
On Monday 05 May 2008 05:13:16 Dan Kegel wrote:
I just wrote up an idea related to release management for post-1.0 wine releases. It's online at http://wiki.winehq.org/TimeBasedReleases Essentially, the idea is to release in March and September, in time for the April and October releases of Ubuntu.
For instance, following this strategy, we might plan to release wine-1.2.0 in September 2008 or March 2009.
I'm against September, as it means we'll go into code freeze _again_ just before Summer of Code finishes.
It might be better to align with SoC, so that we have a release when SoC is finished (with time to properly absorb the changes) and another before it starts, both roughly 6 months apart. This would then make it easier for SoC participants not being in the middle of a code freeze.
While I agree that bi-annual releases sound like a good thing, I'm opposed to forcing it just to make Ubuntu's 8.10 schedule with 1.2.
I agree. If the Wine release schedule slips because of critical bugs, or it is taking longer to apply a really cool SoC feature, then having releases out-of-sync would increase the chance of getting that release into Ubuntu. It also removes implied pressure that we have to release on the specified dates. While the releases should not slip like Xorg appears to be doing, likewise it should not ship if a critical app does not work.
Also, I'm not really sure what this'll mean in terms of features and bug fixes. We certainly don't want to keep people hanging without fixes for bugs for half a year.
We also don't want to slow down development more than needed.
Now, as you state on the wiki page, a bi-weekly release schedule is good for early adopters and developers, as it's centered on "Get my new cool feature in!" rather than on "Will this break Photoshop?". But, and I see you mention that yourself, "Will this break Photoshop?" is a really hard question to answer, especially for developers who don't own photoshop.
I like the bi-weekly releases. These can be seen as bleeding edge test builds (and later, betas and release candidates). They are developmental snapshots that allow people to try the bleeding edge out, where things may break. I highly recommend that we keep these.
Bi-annual releases are good for people who already have their apps working, as prior to a release we probably should make sure nothing breaks. But as fixing new bugs sometimes is a bit hit-and-miss, only being able to try for the wider public once every six months isn't too great.
For people who don't have their apps working, who have a bug or bugs that they are tracking, or who like to stay on the bleeding edge, we should recommend that they try out the bi-weekly releases and continue to file bug reports as is done currently.
For people who's app is working, we should recommend that they stick to a stable release (unless they want to be on the bleeding edge, or help out with testing).
Now, ideally, people should be moving with the bi-weekly releases to pick up any regressions and to test bug fixes. Since Wine has fairly aggressive development with the bi-weekly releases, it may be possible to do quarterly stable releases.
The issue here is how to manage the stable releases. I would like to see the aggressive bi-weekly development continue on wine.git. If we have a wine-stable.git, or wine-1.x.y.git (like the Linux kernel), that gets merged into with the bi-weekly release when code freeze occurs, that can be stabilized to release. I don't know of a better way that would not break either development model.
So assuming we manage to get wine test failures down to 0 during this code freeze, I'm happy to make sure none of my patches breaks anything there. If I can get a similar website for the apps we really don't want to regress, I'll of course try the same for that. But before we don't have that, I don't think it's a good idea.
With the tests, it is critical that the failure rate is as low as possible.
I would also add that the wine todo results are factored in here as well (not for this release, as the window for major changes has closed). This is because those todo items will show up as bugs in real applications, or highlight behavioural differences from Windows. This is assuming that those tests are passing on Windows as well.
I would also argue that any bug must have a corresponding regression test before being fixed, unless there is a good reason for there not being one (e.g. it is a bug in winecfg). This way, Wine is less likely to regress in the future, and the affected app is more likely to continue to work after the fix.
- Reece