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...
- 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&sh...