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