Changes for Wine on Debian

Jens Reyer jre.winesim at gmail.com
Fri Sep 18 23:32:50 CDT 2015


On 09/19/2015 03:48 AM, Kyle Auble wrote:
> On 09/18/2015 01:34 PM, Jens Reyer wrote:
>> Now, for all those wondering about the *usefulness of wine stable*: yes,
>> please!
> 
> I'm not at Wineconf, but isn't Michael S. giving a talk about exactly
> this? I already mentioned my (not very weighty) opinion in another
> email, but I think we should be asking two distinct questions about
> wine's stable release:
> 1. Is there value in having a stable release?
> 2. Should it be decided on upstream and the same for everyone?
> 
> My view is "definitely yes" for #1 but "probably not" for #2. Especially
> with git and the mature infrastructure of the distros these days, it
> makes more sense to me to let each distro follow their own timeline -
> resync their git tree with WineHQ's, pick a dev release to fix as
> stable, create a branch there, then apply their custom patches and
> occasional upstream bug-fixes on top. I get the impression that's the
> approach many of the other flagship FOSS projects have settled into.

Yes of course for #1, but also for #2. There are 1046 commits between
1.5.31 and 1.6.2, from these 687 commits between 1.5.31 (2013-05-24) and
1.6 (2013-08-07). This is an awesome quality effort by winehq.
Of course at some point this is void for a completely outdated stable
release, but imo this is counted in years: Wine has so many use cases,
and much is working even with a years old, but mostly regression free
and thoroughly looked over version.

I think single distributions can't do this, neither by developers
(manpower and technical knowledge), nor by users required for this.
Which distributions actually use development releases as base for their
default Wine release? E.g. kernel releases are first taken care of by
upstream. Only later the distributions take over maintainership.

btw (just my 2 cent): I think dropping release goals would make more
frequent Wine releases, and following this their support, much easier.
Dropping a release goal doesn't mean you don't value the goal, it just
states that it wasn't ready at the release date. There is no loss in
releasing without some new feature. Debian does this by specifying the
next freeze date directly after the release, this turned out to work
much better then waiting for everything being ready.


>> I see the need and usefulness of wine-development for many people, and
>> therefore I promised to maintain them in backports at least for Debian
>> Jessie (i.e. probably the next 2 years).
>> But this is only an additional service for users who have a reason to
>> leave the stable path of their system. The occasional user is happy to
>> know that Wine exists and that it works for an awesome lot of
>> applications (and will do so for the next time, because neither the
>> system or wine will change frequently). I'm sure they are the vast, but
>> silent, majority.
> 
> I can see why WineHQ still recommends the dev release for most users at
> this point. I did have similar concerns to yours though, when I asked in
> my bug report if the "wine-development" package should be part of the
> normal Debian Stable repo. I wanted to ask if both people here at WineHQ
> and at Debian packaging could keep an eye out for relevant data over the
> next year or so.
> 
> Particularly, I wonder...
> 1. Will many questions from Debian Stable users about "wine-development"
> being outdated pop up on the Wine forums or IRC?
> 2. Will the install ratio for Backports vs. Stable "wine-development"
> grow significantly as Jessie ages (if popcon can distinguish between the
> two)?
> 3. Ditto for "wine" vs. "wine-development".
> 
> I'd interpret any of those things as a sign that the frozen version of
> "wine-development" on Stable might be redundant (and the 3rd that you're
> right about most Debian users being fine with the stable release). The
> Debian team could take that into account when deciding what to include
> in Stretch.

There is no version data in popcon. We can only compare wine and
wine-development, and look both at "Installed" (including occasional
users, which are also stable's target group, but also one-time users)
and "Vote" (regular users). atm wine stable leads by a factor of about
20. But interpreting that number and its future changes is quite hard.

Greets
jre



More information about the wine-devel mailing list