Category:OS/4 Hardware

From OS2World.Com Wiki
Jump to navigation Jump to search

This is a list of Hardware tested with the OS/4 project.

This pages's intent is to keep trace of progresses about Phoenix OS/4 development.

All users who are using, are testing or simply desire to test it, can help here team, informing it about compatibility, if model in use is working or not, failures and generally, how bug-fixes go on. Simply keeping trace about progressive svn, time by time. This will inform team about progresses and that tested hardware still works and there are not compatibility issues, backwards-steps, breaks, failures in progress, that potentially, could put in stand-by the development project.

Those wishing to participate, should know that keeping their pages constantly updated is vital for development of the project: if a confirmed hardware, unexpectedly stop to work between few svn releases, developers will understand immediately where are bugs and they will fix them as fast as possible, before go on. If a model/laptop/motherboard does not work anymore tomorrow, try to understand and solve causes, between 5 years, it could be very, very difficult, if the gap will include 4000 or more svn interim releases!

This simple periodic verification technique rather, involve users for very few minutes daily, weekly or at least monthly, but it will be of paramount importance to the team!

This model of developing software, which involves team and users/tester directly, brings to excellent results in short times, and it is more than tested.

Here, we will simply use a variant of this tested model rather than a complex professional development system, hard to manage and to understand for an end user, adapting it to our needs using a different approach, much more friendly, easy to use and that the majority of users know well: The Wiky.

Users, once created their own card, specifying all parameters used to start succesfully the operating system using OS/4, will simply update periodically tested releases, intervening only when and where necessary talking directly to the team for details.

Developers will be able to do their job, knowing that all work fine, that models already tested are always working, which are new models to be tested and what are the problems of each model/series brand, where a drive don't work and when it start to work, and so on, setting the roadmap, job and priority accordingly.

All this, simply updating periodically the svn ID number or version released.

End-users, newbie or testers will enjoy progresses and they will be also happy to test all releases, feeling themselves an active part of the project.