Several releases ago, loading it in WINE worked and I got my smile back. Wish I could remember which release but I didn’t know about ‘regressions’ then so didn’t note it.

Then another upgrade and down it went. I didn’t know then that I could have ‘frozen’ the version that worked. Never ran right again though it did run.

When I re-installed WINE after a major crash followed by a new install of Karmic, nada. Found a near equivalent (close but no cigar) in Open Source and I’ll just have to make do.

Ubuntu was sold to me as an ‘out of the box’ plug and play. It just doesn’t work that way! It’s a system for those of you who enjoy spending at least a quarter of your computer time messing around in a terminal. Next time I have a few bucks, back to Microsoft for me.

You’re gonna be on the mat, on your back, bleeding and lookin’ like you just got run over by some monster, yet you keep coming back fore more. Wow! You guys that chase regression–you are TOUGH!

Keep it up.

If we had an autohotkey magic test for internet explorer, it would have caught the regression too. That would be nice to know even if we commit the patch anyway, as it tells us an important new area to work on.

As for bug 13891, it wasn’t reported until after 1.0 came out, so we didn’t knowingly release a regression

“And by the way, your lobbying about speeding up the Wine release process so 1.2 can get into is not so secret.”

You don’t know about the secret bags of money I’ve been handing out.

Even when changes are absolutely correct, they can cause regressions. Real life example: I implemented (in my local tree) some functions IE7 uses in its favorites implementation. The implementation is (to the best of my knowledge) completely correct. Now IE7 crashes (in my local tree) every time I try to use the favorites.

It happened that Wine is broken in other ways. Because Wine has gotten better, IE7 is actually attempting to show me favorites now, and that crashes for an entirely unrelated reason. It was always broken; I had just never seen it. Before, it had always given up and shown me a blank space.

In this case, my changes would cause a regression as a user would define it: IE7 used to not crash, and now it crashes. Objectively, Wine would be improved. I would even argue that IE7 is behaving more correctly, as it always tries to draw favorites on Windows.

The test suite can (and should) only prevent the kind of regression that happens when Wine gets worse. Every change is supposed to make Wine better than it was before. That’s an ideal we haven’t met, but the test suite makes it a lot easier to do.

That ideal is important. We have to be willing to break applications in the short run (but not during code freeze) so that in the long run Wine can improve its compatibility with Windows.

I don’t think “all the applications that used to work will work in this version” was ever promised in 1.0. If there’s a promise that makes sense, it’s “all the features that used to work correctly will work correctly in this version”, or “we don’t have any major regressions in this version”. I don’t think anyone has made that one either.

Bug 13891 is a major regression that did get into 1.0. There are probably a few others.

Regressions are rarely as easy to fix as reverting a patch. Patches that are completely wrong rarely get into Wine. If we revert a patch that’s partially wrong, we lose the part that’s right too, and Wine gets worse. So we have to fix the regression without giving up the improvements that were introduced. That can be difficult.

And by the way, your lobbying about speeding up the Wine release process so 1.2 can get into is not so secret.

Thanks too for your hard work on Wine. It has saved my bacon a few times in my battle to eschew Windows at work!