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:
- Is there value in having a stable release?
- 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...
- 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