Hello,
According to [1] the criteria for Wine 1.8 is the CSMT patch set. At FOSDEM 2015 Stefan Doesinger said at one moment something like CSMT is not ready yet(I don't remember exactly how he formulated it as he wasn't talking specifically about CSMT).
Wine 1.6 was released in July 2013 [2] so more than 18 months ago. And 1.6 took 15 months to be released.
A lot of good work has been put into 1.7 branch
git rev-list wine-1.6..wine-1.7.35 | wc -l
7708
Currently still a lot of people are using the 1.6 branch. So on the forum Roseanne often has to ask people to upgrade from the stable branch to the development one. On bugzilla, the triagers very often have to close bugs reported on 1.6 and already close in 1.7 (latest example a few hours ago [3])
I do not deny that the work to release is negligible (for example I see that in bugzilla there are 71 bugs tags as regressions [4] for 1.7).
Maybe not having the CSMT patch set would also not be the best PR possible. But the number of commits and bugs solved is clearly good PR and good for the users.
I'm not asking for an immediate release for sure, but to start a discussion on: - maybe a change of criteria for wine-1.8 - a rough schedule for wine-1.8
in order to give most of Wine users the best of what is being produced by you guys.
Cheers, Marc
[1] http://wiki.winehq.org/WineReleaseCriteria [2] https://www.winehq.org/news/2013071801 [3] https://bugs.winehq.org/show_bug.cgi?id=38023 [4] https://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NE...
At FOSDEM, Stefan said CMST was blocked by d3d10 work, which was targeted for "some time this year", IIRC.
The problem of the "Stable" vs "Develop" distinction is kind of lost in a model like Wine's. Users care about things being stable because they don't want what they currently use to break. However, since Wine is always playing catch-up to Windows, you have a lot of bits which are *broken* and get taken care of in further dev releases. So the usual view that "stable is good, master is buggy" is completely wrong and it's not an easy thing to explain to users.
1.8 hasn't been talked about yet publicly that I can tell, so I'd say don't rely on that page too much to tell you exactly when the release comes out. But doing a stable release for the sake of bringing bugfixes from dev releases to users seems futile.
J. Leclanche
2015-02-06 22:15 GMT+01:00 Bessières, Marc marc.bessieres@mykolab.com:
Hello,
According to [1] the criteria for Wine 1.8 is the CSMT patch set. At FOSDEM 2015 Stefan Doesinger said at one moment something like CSMT is not ready yet(I don't remember exactly how he formulated it as he wasn't talking specifically about CSMT).
Wine 1.6 was released in July 2013 [2] so more than 18 months ago. And 1.6 took 15 months to be released.
A lot of good work has been put into 1.7 branch
git rev-list wine-1.6..wine-1.7.35 | wc -l
7708
Currently still a lot of people are using the 1.6 branch. So on the forum Roseanne often has to ask people to upgrade from the stable branch to the development one. On bugzilla, the triagers very often have to close bugs reported on 1.6 and already close in 1.7 (latest example a few hours ago [3])
I do not deny that the work to release is negligible (for example I see that in bugzilla there are 71 bugs tags as regressions [4] for 1.7).
Maybe not having the CSMT patch set would also not be the best PR possible. But the number of commits and bugs solved is clearly good PR and good for the users.
I'm not asking for an immediate release for sure, but to start a discussion on:
- maybe a change of criteria for wine-1.8
- a rough schedule for wine-1.8
in order to give most of Wine users the best of what is being produced by you guys.
Cheers, Marc
[1] http://wiki.winehq.org/WineReleaseCriteria [2] https://www.winehq.org/news/2013071801 [3] https://bugs.winehq.org/show_bug.cgi?id=38023 [4] https://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NE...
On Tue, 10 Feb 2015, Jerome Leclanche wrote: [...]
The problem of the "Stable" vs "Develop" distinction is kind of lost in a model like Wine's. Users care about things being stable because they don't want what they currently use to break. However, since Wine is always playing catch-up to Windows, you have a lot of bits which are *broken* and get taken care of in further dev releases. So the usual view that "stable is good, master is buggy" is completely wrong and it's not an easy thing to explain to users.
Users care that the application they are using does not stop working and that's what can happen with the development branch. So the distinction between stable and development branches does make sense.
And just like in other projects you can be forced to use a development version because of compatibility issues with your hardware or of a feature you absolutely need, in Wine you can be forced to use the development version because of compatibility issues with your Windows applications.
So really the stable / development distinction is no different in Wine than in other projects.
The only thing that sets Wine apart is that it evolves pretty fast and yet has very infrequent stable releases. Hence these problems.
Stable releases matter because we try to guarantee that things will not regress from one stable release to the next. The "best" way to do this is to have good enough unit tests such that things don't regress at all, of course, but that's unfeasible.
One good indicator we should probably start the stable release process is if a significant amount of users are following the beta channel because they expect it to be "better" than the stable channel, which of course depends on which app they want to run. This is a moving target, which implies our decision to start the overhead of another stable release should have something to do with the current state of the world for real human users -- that is, in a hypothetical world where wine1.7 was exactly as different from wine1.6 as it was today, but most users are happily running apps that already work on wine1.6, we could more comfortably delay a release.
Wine1.6 was pretty good a few years ago, but if we're serious about users, we should probably start seriously talking about Wine1.8.
On Wed, Feb 11, 2015 at 12:18 PM, Francois Gouget fgouget@free.fr wrote:
On Tue, 10 Feb 2015, Jerome Leclanche wrote: [...]
The problem of the "Stable" vs "Develop" distinction is kind of lost in a model like Wine's. Users care about things being stable because they don't want what they currently use to break. However, since Wine is always playing catch-up to Windows, you have a lot of bits which are *broken* and get taken care of in further dev releases. So the usual view that "stable is good, master is buggy" is completely wrong and it's not an easy thing to explain to users.
Users care that the application they are using does not stop working and that's what can happen with the development branch. So the distinction between stable and development branches does make sense.
And just like in other projects you can be forced to use a development version because of compatibility issues with your hardware or of a feature you absolutely need, in Wine you can be forced to use the development version because of compatibility issues with your Windows applications.
So really the stable / development distinction is no different in Wine than in other projects.
The only thing that sets Wine apart is that it evolves pretty fast and yet has very infrequent stable releases. Hence these problems.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
On Wed, 11 Feb 2015 21:18:46 +0100 (CET) Francois Gouget fgouget@free.fr wrote:
Users care that the application they are using does not stop working and that's what can happen with the development branch.
That happens in the stable branch, too: when a new major stable release comes out, everything in the development branch goes into it, including unfixed regressions and bugs introduced by new features. The promise of "safe bugfixes only" only applies to minor releases in the stable branch, and most inexperienced users don't realize that.
On Wed, Feb 11, 2015 at 1:56 PM, Rosanne DiMesio dimesio@earthlink.net wrote:
On Wed, 11 Feb 2015 21:18:46 +0100 (CET) Francois Gouget fgouget@free.fr wrote:
Users care that the application they are using does not stop working and that's what can happen with the development branch.
That happens in the stable branch, too: when a new major stable release comes out, everything in the development branch goes into it, including unfixed regressions and bugs introduced by new features. The promise of "safe bugfixes only" only applies to minor releases in the stable branch, and most inexperienced users don't realize that.
To be clear, the whole concept of the "release process" is to generally switch our focus to removing all known regressions and to be even more conservative about introducing code that might cause regressions. By way of comparison, there were only 1 or 2 user-visible regressions going from 1.0 to 1.2, whereas there were something on the order of several hundred at some point between 1.0 and each of the 1.1.x releases.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/11/2015 09:18 PM, Francois Gouget wrote:
So really the stable / development distinction is no different in Wine than in other projects.
The only thing that sets Wine apart is that it evolves pretty fast and yet has very infrequent stable releases. Hence these problems.
That!
It would have been fine if 1.8 would have seen the light in summer 2014 as initially planned. That would have been 1 year after 1.6.
But now it is 1 year after the 1.6.2 (last) stable release and that is broken on any modern system with gcc >= 4.9 https://bugs.winehq.org/show_bug.cgi?id=36139#c17
Version 1.8 is not even in sight as the two major features Android and CSMT are still far away. At least for the CSMT there is publicly available code (thanks Stefan!) but for Android we're in the dark.
So yeah, there is a reason why I added "Wine Stable Considered Harmful" as a topic for the next WineConf...
bye michael
-
Bessières, Marc -
Francois Gouget -
Jerome Leclanche -
Michael Stefaniuc -
Rosanne DiMesio -
Scott Ritchie