[pkg-wine-party] wine plan for stretch

[Jens Reyer]

On 19.12.2016 03:44, Michael Gilbert wrote:
> Here is my plan for stretch.  Wine 2.0 is coming soon, but not soon
> enough, so I don't plan to promote it to plain wine.
> 
> So at stretch release, wine will be 1.8.something and wine-development
> will be 2.0.something.

I expect the timetable to be tight, but not a problem. What dates do you
have in mind?

Debian soft freeze is on January 5th, but that shouldn't affect us,
because wine is in testing. Hard freeze is on February 5th, so the last
chance for us to upload is ~ January 25th.

Wine 1.8 had 4 release candidates.

There were these releases:
2016-01-09: 1.9.1
2016-12-25: 1.9.0
2015-12-19: 1.8
... so I don't expect a holiday break for Winehq releases.

Wine 2.0-rc2 was released on December 16th. So 2.0-rc4 might be on
December 30th and 2.0 on January 6th.

Going by that there's room for 2 more release candidates compared to
1.8. A Winehq release on January 20th should still be fine for us.

I'm quite sure we have a 2.0 by then, but I'd also be ok to go with Wine
2.0-rc7 for Stretch.

I might ask upstream if they think it's reasonable to expect a Wine
release till January 20th.




However, assuming all above is right, I'd suggest to start moving to
src:wine earlier, so we have a bit more time for testing the switch (at
least 2 weeks).

Generally I don't expect much/any trouble of this, since there weren't
many reports in the bts lately, and since the debian packaging of wine
and wine-development has been quite close for a longer time now.



I wanted to discuss this anyway: What do you think about pushing Wine
stable updates (2.0.x) to stable-proposed later? Of course we also need
to discuss this with the release team, but that would be especially
interesting if we end up shipping a release candidate initially.

I see the Winehq stable point releases as bugfix only releases. While we
currently see most of the addressed bugs as "minor" in the Debian bts, I
consider the sum of them to be "important".

Some (rather quick) data points:

Rules for patches going into Wine Stable
(https://wiki.winehq.org/Stable_Rules):

* It must be first accepted in the Development version (in exceptional
cases it can come via Staging).
* It must be tested (in 1-2 released Development or Staging versions).
* It should be small.
* It must fix a real bug in a real application.
* Stubs must get an application to run (not to just crash later) and
need a longer testing period in the wild.
* It must fix a build issue, especially on distributions using Wine Stable.
* Translation updates are in scope too.

The stable maintainer (still) tries to reduce the number of commits.
Current history:
1.8.5: 64
1.8.4: 71
1.8.3: 86
1.8.2: 98
1.8.1: 36

AFAIK there was only one regression so far in Wine stable. But that was
a somewhat severe one, because it broke MS Office. That happened in
1.8.5 and the maintainer will be even more cautious in the future.

Of course we can only decide when we have an actual 2.0.1. But I can
imagine that it would work as long as we wait e.g. 1-2 months after an
upstream release before uploading to stable-proposed, and dig through
the upstream bugreports to make sure there are no known regressions.



> For buster, I think it will be better to use version numbers as the
> suffix for the binary packages in case we end up in a similar
> situation with two "stable" versions at the same time.

No hard opinion on this.

I assume you would want e.g. wine2.0 and wine2.2 to be co-installable.
So we would probably set VERSION to the version number.

Pro:
- Two "stable" versions at the same time possible.
- No confusion what's newer, wine or wine-development.
- Allows us to drop "DEBSUFFIX" again, which I had to add for the
alternatives system.

Con:
- Stable Wine wouldn't have the unsuffixed directory name anymore. That
might break other software (in or outside of Debian, or some random user
script). But I have nothing special in mind.

Further we'd probably add a metapackage "wine", to manage automatic
updates for users.

Greets
jre