I`ll participate in testing team, no matter what shape or methode will be chosen, this is above discussion. The approach should be discussed though.
In the years i`ve been with ROS, we had a remarkable increase in stability, from the point when you had to be careful to finish up the planned test, so ReactOS doesnt hang in the process, to the point when you actually have to try hard to crash it. Certainly, we are stilll miles from being rock solid, but the progress has been made. We have one primary problem with our project: too many problems at the same time. Its not only stability (with Mm, Cc and vfat issues) or hardware support (unimplemented PnP and HAL, busted resource reporting), or Win32 subsystem issues Timo has pointed. At the same time we have problems with WINE userland and their approach to implementation, general code untidyness, header mess, miriads of old and often undocumented hacks, on which future assumptions were made, rbuild/compiler issues, lack of decent debugging tools, general lack of manpower in all areas, lack of standarised testing platform as well as problems determining our future goals or attracting more publicity. I think you could add a bunch more.
You know what? We try to solve all of those problems at once. And yet we are unable to finish off a single one.
Yes, that's why I always tell, and will do keep telling: Test your code against a solid base! If you develop a driver, debug and test it in Windows, and then fix ReactOS. If you develop an application or CPL applet, develop it in Windows, and then fix ReactOS if needed.
Fortunately, that seems to finally work, and there are places we can trust (there are many which we can't - yet). Certainly, the old ReactOS way of "let's hack driver to fit hacked kernel" has gone long time ago, and that was the case of "solving all problems at once".
One more thing - wine test fixing week, or other common-problem- fixing week is a nice thing, and I think we really could do some.
WBR, Aleksey Bragin.
On Apr 9, 2009, at 12:56 AM, Olaf Siejka wrote:
I`ll participate in testing team, no matter what shape or methode will be chosen, this is above discussion. The approach should be discussed though.
In the years i`ve been with ROS, we had a remarkable increase in stability, from the point when you had to be careful to finish up the planned test, so ReactOS doesnt hang in the process, to the point when you actually have to try hard to crash it. Certainly, we are stilll miles from being rock solid, but the progress has been made. We have one primary problem with our project: too many problems at the same time. Its not only stability (with Mm, Cc and vfat issues) or hardware support (unimplemented PnP and HAL, busted resource reporting), or Win32 subsystem issues Timo has pointed. At the same time we have problems with WINE userland and their approach to implementation, general code untidyness, header mess, miriads of old and often undocumented hacks, on which future assumptions were made, rbuild/compiler issues, lack of decent debugging tools, general lack of manpower in all areas, lack of standarised testing platform as well as problems determining our future goals or attracting more publicity. I think you could add a bunch more.
You know what? We try to solve all of those problems at once. And yet we are unable to finish off a single one.
-
Aleksey Bragin -
Olaf Siejka