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 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
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 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
Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off CodeWeavers CrossOver+ today.
No comments:
Post a Comment