Thoughts on Wine's development model...

Scott Ritchie has just blogged about the need for a new Wine stable release. Everything he says in the post, of course, makes perfect sense. Both distributions and the Wine project itself would benefit from a new stable release. But I think the lack of releases actually stems from a more fundamental problem with Wine's development model as a whole.

The Wine repository gatekeeper is Alexandre Julliard, who is notoriously strict about the quality of the patches he accepts. To contribute code to Wine, you should mail a patch to the wine-patches mailing list, AJ and other developers watching the list will check your patches and give you lengthy feedback about how to improve your patch if it is not accepted. At least, I think that's the idea behind wine-patches. In reality, if your patch is rejected or accepted, you likely won't be notified at all. There only seem to be two ways to get feedback, firstly, if your patch happens to wonder onto the turf of a Wine developer (e.g. a subsystem they maintain), then you may get feedback from them, alternatively you can wait a day or two then pester AJ on #winehackers for feedback. The most common outcome if your patch is rejected though is that it disappears into they abyss of the wine-patches archives for an eternity of bit-rotting. This is a real shame, I would hazard a guess that 60% of patches which hit wine-patches are almost right and just need minor fixes, but are rejected. And I guesstimate 50% of those patches are never ever resubmitted and just disappear.

I believe the reason that it is so difficult to get patches into Wine is that there is NO development branch. OK, theoretically there is the 1.0.x branch which is stable and the 1.1.x branch which isn't, but releases are so rare that the stable branch is obsolete and the development branch is the branch you are supposed to use.

This leads to major problems aside from those mentioned in Scott's blog post. One of these such problems is the inability to make any major structural change to Wine.

As an example, recently a guy called Max spent time writing a DIB engine. DIB handling in Wine is quite slow, and the DIB engine is supposed to rectify that situation. Despite Max writing a working DIB engine which passed the Wine tests and showed speed improvements in several apps it was not accepted, the reasoning for which is quite sound; the design was wrong. But why was the design wrong? Why did Max spend ages writing something which he knew would never be accepted? Because to implement it properly would cause mass breakage because it required fundamental changes to Wine (specifically gdi32.dll). AJ won't accept patches which cause mass breakage because the development branch is essentially the ONLY branch.

Here's the catch 22. Wine needs regular releases to allow for big structural changes and Wine doesn't have regular releases because the criteria for the next regular release require big structural changes.

What's the solution? I think the best solution is to right now create a stable branch from the development branch. For the next 6 months, stablize that branch, add no new features just bug fixes. In the mean time open the flood gates for massive changes and not-quite-right-but-nearly-there patches into the development branch. After 6 months release a new stable version based on the stable branch and then once that release is done, sync the development branch to the stable branch to begin another 6 month stablization cycle.

This is exactly what Ubuntu does with Debian Experimental. At the start of each release cycle, sync from the unstable branch and spend 6 months stablizing it. Wine should do the same. This method has many benefits:

1. If a patch is sent that isn't quite right, then it can be accepted into the development branch anyway to be fixed up.
2. Big structural changes can happen
3. Wine development would be easier to get into, meaning more devs, meaning faster progress.

If this cycle was adopted, then some kind of semi-automated means of getting patches into wine-unstable would be nice, with AJ remaining in charge of wine-stable. I'm thinking of some website which displays the patches sent to wine-patches. Developers can vote a patch up or down and comment on it. If a patch gets 3 votes up, it automatically is committed, if it gets 3 votes down it is rejected. Wishful thinking I know, but that would be awesome ;)