[ros-dev] Brainstorming about testing team, roadmap and ReactOS usability
aleksey at reactos.org
Wed Apr 8 12:06:49 CEST 2009
I had a chat with Olaf a few days ago, regarding a few issues, and we
thought it would be beneficial to bring them up for collective
Background information: In the past and nowadays work in ReactOS is
getting done "as it flows". E.g. if we get developers, who wanted to
implement sound support, would do it, and we advertise this in a
release. Or, like Evgeniy Boltik who shows a nice cooperation with
Timo, Jim and Ged on fixing various nasty palette and drawing issues
which were not touched for a few years, often fixing errors
introduced in revisions like 1000 or 4000.
There is no central plan, just a very rough roadmap, mainly
Same applies to testing team: we usually perform testing when an
obvious problem occurs, in our very well known apps list, which
someone remembers to work in a certain revision. If that's known to
regress, Olaf usually organizes a regression-testing, a guilty
revision is found, and problem hopefully gets fixed.
All of this is very good, for an operating system which is developed
just for the sake of development: noone sets any milestones, noone
demands to meet them. And noone pays for achieving them either.
But when Linux got a real spin-off? An answer is: when it aimed to
become useful for the most needed application - as a platform to run
a web server and a mail server. http://en.wikipedia.org/wiki/
Linux_adoption says that in 2001 Linux servers experienced 15% annual
growth rate, and by 2004 50% of the worldwide blade servers are
shipped with Linux-based OS.
This was preceded by hard work of a number of people, like Andrew
Morton. Who aimed not just at gettign more and more features, but
more at getting existing code as stable as it's possible. That
included going through all the issues people reported, asking them to
provide more info if needed, finding the actual bug, fixing it,
asking them to retest... At some point all most frequently
encountered bugs were fixed, and potential Linux usage base extended
For ReactOS, we have different aims, but we could use this strategy
now, when core parts of our operating system are becoming feature-
complete and mostly need debugging, and when we finally are getting
very close to going Beta.
This involves, first of all, getting hardware support at a decent
level. From a billion of personal computers in the world, we could
easily support the most common hardware without need to develop
complex drivers or different HALs. Even SATA would not really be a
strong requirement, since most of PCs have IDE compatibility mode,
which many non-technical people even forget to switch to "SATA" mode
in the BIOS when installing their Windows OS! Again Linux's
philisophy could help us: they are proud that their hardware is Linux-
compatible, while we are embarrased that "our OS doesn't support
specific hardware". Feel the difference.
Some good step in this direction is this wikipage: http://
Next, software. We have a unique situation when our OS targets a vast
amount of WinAPI compatible software. There is a lot of bugs in our
Win32 subsystem, however if we can find a set of apps we support
right now, or find common software which we could easily support - it
should be our "road ahead".
Now back to what I started writing this email about. I was speaking
with Olaf and Klemens about the software compatibility database.
Existing "Support Database" is not used by people, and not liked by
most of our developers and testers because it takes more time to file
an entry into that database than to actually install ReactOS and test
the app. Another problem is that community-driven database won't work
since we can't confirm people's data.
What we thought would work good so far is a list of working apps. As
Olaf said: "it'll be ugly, not scientifically statistically fine,
crude comparing to wine appdb and limited. Bit it can be done". The
amount of text to enter for an app entry must be as minimal as
possible: app name, platform (real hardware, emulator), bug number in
bugzilla for possible issues (max. 2 bugs for one entry).
Also, no division for "installs, but doesn't start" or "works only
via manual installation". Either it works, or it doesn't, no
As we thought later, it may even be just three columns: appname, ROS
A wikipage could suit this need, but if necessary, we could think
further of some web-app.
I think that's enough for one email, I'll be glad to listen to
comments and more ideas. Everyone is welcome to take part in the
With the best regards,
More information about the Ros-dev