Article on wine development strategy

[David Gerard]

2009/4/18 Scott Ritchie <scott at open-vote.org>:

> Thank you Dan, you reminded me to forward my blog post to the list ;)


I'm not sure how to put this into your simulation as described, but
there's another effect that's important: the good-enough-to-be-beta
effect.

I'd say there was a significant upturn in Wine's quality around 0.9.
That's where Wine crossed from being an interesting idea into
something good enough to actually use - where it was good enough for
actual users, so more users meant more bug reports. Yay bug reports!

I got a similar feeling around Mozilla 0.9 - where this fat,
lumbering, bug-riddled, crash-prone browser that was nevertheless very
important crossed some line and ... was more usable than not. I
believe it was the stability push between 0.8.1 and 0.9 that did that.

Another important comment on your post links to an idea Wine needs:
crash reporting. Just like Windows does.

https://winqual.microsoft.com/help/About_Windows_Error_Reporting_for_Hardware.htm
http://www.codinghorror.com/blog/archives/001239.html

Note that the latter post advocates this for the Wine development
model of fixing bugs as they're a problem: "Although I remain a fan of
test driven development, the speculative nature of the time investment
is one problem I've always had with it. If you fix a bug that no
actual user will ever encounter, what have you actually fixed? While
there are many other valid reasons to practice TDD, as a pure bug
fixing mechanism it's always seemed far too much like premature
optimization for my tastes. I'd much rather spend my time fixing bugs
that are problems in practice rather than theory."

I wonder how much work crash reporting would be to add to Wine.

The importance of automatic reporting, of course, is that if you rely
on your users to complain actively then you've already lost.


- d.




- d.