On 07/24/2015 01:46 AM, Michael Stefaniuc wrote:
We already have a topic "Wine Stable Considered Harmful" for the WineConf in September, see http://wiki.winehq.org/WineConf2015
...
On a high level view this are IMHO the good and bad things about the current stable process in Wine:
Good Bad
Code freeze/stabilization Way too old Marketing Release slips with features slippage Some distributions want it Distributions insist on using it Bug reports for stable are ignored
When you think about it, isn't the idea of a separate, stable release by upstream a hold-over from the days before distributed VCS became widespread? I mean, a stable release is useful partly because it signifies upstream has invested a lot of time in testing and clearing out the bugs from existing features, which is still just as important as ever. At the same time though, it served an administrative function; if you were more involved downstream, how easy was it to stick your own patches on top of a moving target upstream without easy merging & rebasing?
It seems like other major projects, e.g. mozilla and the linux kernel, switched over to a rapid-release schedule soon after migrating their code to a DCVS. Funny enough, if you look back at old issues of WWN, even wine converged to the bimonthly release soon after dumping CVS. At this point, I figure it's still important to have regular code freezes and bug-hunts (perhaps even more often, like semi-annually?) Nowadays though, it makes a lot more sense than it once did, to let the distros decide which one of those to branch from and make their "stable."
It's an interesting question actually, how the technology effects the organization. It should probably be in a new thread, but I imagine there are some other procedures the project could revamp to fit the newer tools.
- Kyle