[ros-dev] Brainstorming about testing team, roadmap and ReactOS usability

[Steven Edwards]

On Wed, Apr 8, 2009 at 6:06 AM, Aleksey Bragin <aleksey at reactos.org> wrote:
> 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
> relatively short-term.

Everyone is doing a great job nailing down these issues!

<snip>

> 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.

Yes its a mental shift, but a hard one to adopt. ReactOS having more
value over other operating systems is the selling point. Linux has
been able to show its value over Windows in certain situations, and
that value is greater than the hardware support value. An example,
Google runs Linux, Google could not have built its network running
Windows due to licensing costs. Therefore Linux has more value than
Windows in that situation. It makes it worth the effort to find
hardware that is Linux compatible.

ReactOS related comments at the end....

<snip>
> 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
> intermediate stages.
> As we thought later, it may even be just three columns: appname, ROS
> revision, Comments.

I agree with this. All software has bugs. I think the (Works/Does Not
Work) is a point of view, of 'can I use this software even with its
bugs?'. If yes, then it works. If not, then it does not work.

Now back to the value thing. Windows costs money, ReactOS can now run
hardware GL and Wine DirectX in select virtual machines. If you want
to show the value of ReactOS its time to make ReactOS run as many
Windows games as possible in these virtual machines on Apple Hardware.
This will save OS X users the need to dual boot or acquire a Windows
license. Also hardware support is not a big problem, which again helps
us. This is the future.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo