Ports

For AROS 1.0 to be released, these requirements must be fulfilled by the i386-pc and i386-linux ports (referred to as "mandatory ports" below). Other ports are not seen as required for 1.0, to keep the amount of work down.

Requirements

As the current status can`t be objectively estimated in percents, we can try to give only the qualitative estimation for these points. Also the further recomendations can be highlited.

1. AmigaOS 3.1 API compatibility, excluding parts which are deemed to be non-portable or obsolete and not worth the effort.

   To mark something as obsolete even though it is possible to implement in a portable way should require good reasons; for example if it is very rarely used by applications and the effort required to implement it is substantial.

   Current status: Most of the AmigaOS 3.1 API was implemented and even superceeded in some parts. (Not that missing hardware Amiga parts like lowlevel.lib, card.device, gameport, audio.device have not been implemented or been replaced). Although, it needs a good bugfixing work done.

2. Partial AmigaOS 3.5 and 3.9 API compatibility. We choose the parts that we feel are useful and worthwhile to have, and ditch the rest.

   For example, it seems very unlikely that we want ReAction compatibility since we have already chosen to standardize on Zune for the GUI toolkit (and implementing the ReAction API is not a trivial undertaking). Of course, this will have to be discussed properly before a detailed list is agreed upon.

   Current status: <?>

3. Completed GUI toolkit. This means Zune must have complete MUI API compatability and a finished preferences program.

   Current status: Almost done. Preferences editor misses some functions.

4. Standard applications comparable to those which come with AmigaOS 3.1.

   This does not mean that we have to have the exact same applications which work exactly the same as in AmigaOS, but the functionality available to the user should be roughly equivalent.

   Current status: Most of that basic applications have been developed.

• Missing are:
  • Overscan (FIXME:not really needed)
  • Palette (FIXME:not really needed)
  • Pointer
  • Printer (absent)
  • Sound (it`s different - we have AHI prefs)
  • WBPattern (we have Wanderer prefs, which is in works)
  • Workbench (we have Wanderer prefs, which is in works)

5. Sound support, meaning API compatibility and basic applications. There should be at least one driver for each mandatory port.

   Current status: Currently AHI is ported, and there`s some drivers (a few) for i386-port. Applications are in development; Madahi and MP3 player are available). (FIXME: to clear out - must those applications code be included to the system or just made available, or isn`t that necessary?).

6. Networking support. This includes a TCP/IP-stack and some basic applications like email and SSH clients, and also a simple web browser. There should be at least one NIC driver for each mandatory port.

   The requirements on the web browser should not be high, but it should be possible to at least browse the web in some way (even if it is only in text mode).

   Current status: AROSTCP we got now is ancient but working implementation of AmiTCP stack. Some applications was developed (i.e. the FTP and telnet client, IRC-client) but it isn`t a part of the system itself. Other applications including some possible browser implementations is in works.

7. Self-hosted development environment and SDK for developers. Specifically, this includes all software required to build AROS like GCC, GNU binutils, GNU make and the rest. It must be possible to compile AROS on AROS.

   The ABI for the supported architectures (only i386 at this point) must be finalized before 1.0. Once 1.0 is released, the ABI should be stable for a considerable time.

   Current status: AROS got a full gcc port, allowing to compile applications but some GNU tools are still missing, so the self-compiling isn`t possible at the moment.

• Missing are: (Fixme)
  • GNU AWK (GAWK) or other awks
  • Python 2.2.1+ (an old port of python is available though)
  • Bison
  • Flex
  • pngtopnm and ppmtoilbm (part of the netpbm package)
  • Autoconf
  • Automake
  • Common unix utilities like cp, mv, sort, uniq, head, ...

8. Comprehensive documentation for developers. This includes complete reference manuals over all libraries, devices, classes and development tools and also guides and tutorials to introduce whole subsystems and give an overview. Also, a migration/porting guide should be available.

   Current status: <?>

9. Comprehensive documentation for users. This includes a complete command reference, tutorials and installation-, configuration- and other guides.

   Current status: Documentation exists and extensively translated to different languages. Still needs the tutorials and guides, and the help system to be complete.

10. Substantial testing and bug hunting complete. The 1.0 release should be virtually free of bugs, and be a very stable release. We should not have the fiascos some open source projects have had with their ".0" releases.

    This will probably require an extended feature freeze, followed by a code freeze and several intermediate milestones for user feedback and testing. Feature requests are not regarded as bugs, unless it is something required (but missed) in the preceding milestones. For example, "we need a movie player" does not qualify, but "the text editor should have a 'save' menu option" does.

    Current status: Currently no freeze can be done as features isn`t complete yet. There`s still lot of unfixed bugs, but increasing users activity looks promising. Bug hunting and accounting procedures and services are wanted.

Overall Status <to be done>

Recomendations <to be done>