Wine Stable (Was: Re: [website] Update Debian downloads info (Resend))
Kyle Auble
kyle.auble at zoho.com
Sun Jul 26 01:24:29 CDT 2015
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
More information about the wine-devel
mailing list