Time-based releases idea

[Reece Dunn]

2008/5/5 Kai Blin <kai.blin at 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