-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, at WineConf we had a fairly uncontroversial discussion about the Wine Stable release process. As the current process of feature based Wine releases isn't working(*) following changes were agreed upon. Release Process Changes - ----------------------- - - Switch to time based releases. - - Major releases once a year in autumn/fall. Code freeze starts around mid/end of September. - - Michael Stefaniuc will be the stable maintainer starting with 1.8.x. Other people are more than welcome to help out with Wine Stable. I'll document stuff and send out a request for help during the code freeze. - - The stable release will be supported in bugzilla. - - This changes take effect immediately. You can expect Alexandre to announce a code freeze in the next couple of weeks. - - We will revisit this changes should the need arise, e.g. reduce the time between two major stable releases. Discussion - ---------- The discussion was done based on slide 9 of Alexandre's keynote http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=wineconf... At the start Alexandre and others noted that we do not hear from users for whom 1.6 is just working. We are getting reports only about the stuff that breaks. The discussion quickly geared to the changes accepted from above with the focus on implementation details: - - 6 months better? No, the 12-18 months stable release cadence prior to 1.8 was ok. Can be reduced later on should the need arise. - - Synchronize with (a) major distro? No, release dates can slip on both ends. Freeze should also not impact GSoC. - - Nobody else volunteered during the discussion for the stable maintainer role. For the more drastic proposal of removing the the Wine Stable version altogether, Alexandre made drafted a plan to follow a similar model to the Linux Kernel. One release for the risky stuff and every second release is for stabilization. He proposed also a two weeks "merge window" for risky stuff followed by two weeks for the fixes and the last two weeks of "freeze". This produced a loud outcry from most developers: it would be unworkable without a prior move to a git pull model to accept new features. This basically killed the proposal. (*) 1.6 released > 2 years ago and was latest updated 1.5 years ago. It doesn't compiles on a modern distribution anymore. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFWAT4O0ei8kcpE1VERAprfAKC0x+Zb6zHGv095REWGGYy+L/qsBQCgpr1+ Z9VxsMM7J1/wdpAyC8DPJaE= =zhZ8 -----END PGP SIGNATURE-----
On 09/22/2015 01:39 PM, Michael Stefaniuc wrote:
Hello,
at WineConf we had a fairly uncontroversial discussion about the Wine Stable release process. As the current process of feature based Wine releases isn't working(*) following changes were agreed upon.
Release Process Changes ----------------------- - Switch to time based releases.
- Major releases once a year in autumn/fall. Code freeze starts around mid/end of September.
- Michael Stefaniuc will be the stable maintainer starting with 1.8.x. Other people are more than welcome to help out with Wine Stable. I'll document stuff and send out a request for help during the code freeze.
- The stable release will be supported in bugzilla.
- This changes take effect immediately. You can expect Alexandre to announce a code freeze in the next couple of weeks.
- We will revisit this changes should the need arise, e.g. reduce the time between two major stable releases. [...]
Awesome, thank you all and especially thank you Michael! This sounds generally good and looks like fitting perfectly for Debian, which currently freezes in November/December. Greets jre
On Tue, 22 Sep 2015, Michael Stefaniuc wrote:
Hello,
at WineConf we had a fairly uncontroversial discussion about the Wine Stable release process. As the current process of feature based Wine releases isn't working(*) following changes were agreed upon.
I tried to make it a bit more controversial by suggesting that some Wine Staging patches should maybe go into the Wine Stable release. But that did not get very far. The rationale is that Wine Stable is targeted at end users, not developers. End users don't care that a patch is ugly and should not go into mainline Wine for various reasons. All they care about is that their applications work. So it could make sense to include carefully selected Wine Staging patches that have been around for some time and have not caused regressions. The main drawback is that it would make comparing Wine Stable with plain Wine a bit harder: normally we would ask Wine Stable users to test their broken application in plain Wine to see if it's fixed. But now the application may not even start due to the lack of one of these extra patches (rather than a simple regression). So I don't think there's one right answer on this matter. It's more about where to put the cursor between user-friendliness and development speed / ease; and figuring out what will work best in the end for Wine. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A man can fail many times, but he isn't a failure until he begins to blame somebody else. -- John Burroughs
On 09/25/2015 12:45 PM, Francois Gouget wrote:
On Tue, 22 Sep 2015, Michael Stefaniuc wrote:
at WineConf we had a fairly uncontroversial discussion about the Wine Stable release process. As the current process of feature based Wine releases isn't working(*) following changes were agreed upon.
I tried to make it a bit more controversial by suggesting that some Wine Staging patches should maybe go into the Wine Stable release. But that did not get very far.
The rationale is that Wine Stable is targeted at end users, not developers. End users don't care that a patch is ugly and should not go into mainline Wine for various reasons. All they care about is that their applications work. So it could make sense to include carefully selected Wine Staging patches that have been around for some time and have not caused regressions. Only for regression fixes that are hard to do right and where reverting the original patch would regress a different set of applications. For the rest the patch needs to go through the development branch.
The main drawback is that it would make comparing Wine Stable with plain Wine a bit harder: normally we would ask Wine Stable users to test their I see Wine Stable primary used for all those 20+K applications that just work today. For the users from whom we do not hear anything because Wine just works. For the others we will provide development and staging binaries, no need to hack up stable for that.
broken application in plain Wine to see if it's fixed. But now the application may not even start due to the lack of one of these extra patches (rather than a simple regression).
So I don't think there's one right answer on this matter. It's more about where to put the cursor between user-friendliness and development speed / ease; and figuring out what will work best in the end for Wine. For me "user-friendliness" in the context of Wine Stable means: "No regressions".
bye michael
So I don't think there's one right answer on this matter. It's more about where to put the cursor between user-friendliness and development speed / ease; and figuring out what will work best in the end for Wine. For me "user-friendliness" in the context of Wine Stable means: "No regressions".
I strongly agree. If I choose to use the stable version of Wine, I do not want any surprises when I do an apt-get upgrade. Particularly if I deliberately chose stable over the other two options. Cheers, Jeremy
On Fri, 25 Sep 2015 07:48:40 -0500 Jeremy White <jwhite(a)codeweavers.com> wrote:
I strongly agree. If I choose to use the stable version of Wine, I do not want any surprises when I do an apt-get upgrade. Particularly if I deliberately chose stable over the other two options.
+1 -- Rosanne DiMesio <dimesio(a)earthlink.net>
On Fri, Sep 25, 2015 at 6:18 PM, Jeremy White <jwhite(a)codeweavers.com> wrote:
So I don't think there's one right answer on this matter. It's more
about where to put the cursor between user-friendliness and development speed / ease; and figuring out what will work best in the end for Wine.
For me "user-friendliness" in the context of Wine Stable means: "No regressions".
I strongly agree. If I choose to use the stable version of Wine, I do not want any surprises when I do an apt-get upgrade. Particularly if I deliberately chose stable over the other two options.
Cheers,
Jeremy
+1 I agree with Michael's points on wine stable. Also I guess this would work well with the code-freeze, where IIRC there should be enough time for regression checks on patches which have potential to go on wine stable. But I guess it all comes down to how it all goes during the first couple releases.
Cheers, Aaryaman Cheers, Aaryaman
participants (6)
-
Aaryaman Vasishta -
Francois Gouget -
Jens Reyer -
Jeremy White -
Michael Stefaniuc -
Rosanne DiMesio