There are three primary ways to find bugs (1) Bugs reports from users. (2) Regression testing (4) Proof reading the code These ways has several problems. Bug reports from users (1a) How can we get the user to send in a bug report? (1b) How can we help the user detect that a bug exists? (1c) How can we help to the user to send in a good bug report? (1d) How can we know if this really is a Wine problem? (1e) What is the real cause of the problem? Regression testing (2a) How can we get developers to write regression tests? (2b) How can we get developers to run the regression tests? (2c) Why did the test fail? Proof reading the code (3a) How can we get developers to proof read the code? (3b) Why is the code reported as incorrect? The motivation points (1a,2a,2b,3a) can seem trivial but I think they are more important that most people realize. For example if we send most bugs reports to /dev/null, it will make users less likely to send in bug reports. As for myself I have as most of you know been working on and maintaining a static code analysis tool (3a) called winapi_check, soon to be followed by a regression tester (2a) called winapi_test. Anyway, lets concentrate on (1), eventhough I personally thinks that that approach has large limitations because it will, as Wine get better and better, be harder and harder to find problems that way, since it will be for each version be less and less certain that the a detected problem really is a Wine problem and not a problem with the application. This is especially true if you try to find bugs by assuming that application will not for example call API:s with NULL values under normal circumstanses. Currently we have a simple debug message reporting that basicly assumes that a problem can be detected by a simple test of some local state. Since this isn't true in general and by now most problem that can have already been fixed. So what what we must do is doing something radically different. The question is what exactly what? This is a good question that I don't really have a good answer to. But lets do some brainstorming, meaning that not all suggestions are serious. * We could introduce some ASSERT like macros that as default does WARN, but could be runtime configured to do something else. * We could introduce some kind of magic null handles that if passed to a normal API will trigger an error or something. * We could keep some sort of internal log of functions that failed and if a related function later also fails it can display a more intelligent error message. * We could write some sort of Wine for Windows that in principle only implements the debug messages so we more easy could compare Wine and Windows. Any more suggestions?
