Changes for Wine on Debian

[Kyle Auble]

On 09/19/2015 12:48 PM, Michael Gilbert wrote:
> On Fri, Sep 18, 2015 at 9:48 PM, Kyle Auble wrote:
>> Particularly, I wonder...
>> 1. Will many questions from Debian Stable users about "wine-development"
>> being outdated pop up on the Wine forums or IRC?
> I doubt this as a practical problem.  You can always tell them to
> reproduce it with a newer version, pointing them to the wiki page
> about Debian's backport packages.

You're right, it's definitely not a major problem; I was more interested 
in keeping tabs on how often it happens as a data-point. I'm just 
wondering if the confusion earlier this summer was a one-time thing or 
if it will keep recurring even as word gets out about the 
wine-development package.

On 09/19/2015 12:48 PM, Michael Gilbert wrote:
> I don't think the popcon interface can query for backports vs. stable numbers.

On 09/18/2015 10:32 PM, Jens Reyer wrote:
> 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).

I thought that might be the case when I tried looking for the data. It 
surprised me a little though because I figure including the package 
version in the popcon reports wouldn't be too hard. If there's not 
something else preventing it (like security), that might be something I 
look into down the road.

On 09/19/2015 12:48 PM, Michael Gilbert wrote:
> The data [0] shows users favoring the stable release by a factor of
> 20:1; granted this is only year one with a development package being
> available that is only 4 months in Debian stable, and more than 10
> years with the stable package.
>
> That data also shows interest in the stable version stagnating, and
> interest in the development version growing.

Yeah, "wine-development" is still too young to claim anything from the 
data, but I noticed the trend too. What I found interesting is if you 
actually break apart the data for "wine" into the four different fields, 
there's still growth in the number of recent users (though "old" users 
are increasing faster); most of the stagnation in total installations 
comes from a massive drop in the number of "no-files" [1].

On 09/19/2015 12:48 PM, Michael Gilbert wrote:
> Anyway, somewhat unexpectedly different user have different needs.
> Some favor stability, and others favor bleeding edge.  That is why
> there are longterm, stable, mainline, next, and various other linux
> kernel versions available to pick from.  Why not support them all at
> least in some way?  Upstream really needs to take the lead on making
> those decisions, otherwise distributions have no idea which to pick
> from, and end up with an arbitrary snapshot.

On 09/18/2015 10:32 PM, Jens Reyer wrote:
> 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 think we actually agree for the most part and I've been using the 
phrase "development release" in a confused way (in the sense of a 
regular release from the tip of mainline, not in the sense that there 
hasn't been any code-freeze or focus on QA... I probably have Wine's 
release schedule in mind). You're both absolutely right that the 
release-candidate procedures should be handled upstream, plus the more 
regularly they happen, the better.

It's interesting you both mentioned the Linux kernel too because that's 
the example I had in mind (along with Firefox and Chrome). They don't 
have alternating stable and development versions anymore, but rather use 
branches off of mainline more liberally. I didn't think of it at first, 
but you're also right that it makes a lot of sense for all those 
branches to be hosted upstream.

At the same time, aren't the actual branches managed independently? That 
was the picture in my head when I said I thought downstream should have 
more say in deciding which release is stable. After thinking about what 
you both said, I can see that probably isn't the right approach, but I 
still feel like even if the branches happen under one roof, they should 
fall to independent teams.

Once everyone gets back from Wineconf though, it will be interesting to 
see if a consensus is forming on the stable vs. development question.

- Kyle

[1] 
https://qa.debian.org/popcon-graph.php?packages=wine&show_vote=on&show_old=on&show_recent=on&show_nofiles=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y&beenhere=1