27 lines
3.8 KiB
Plaintext
27 lines
3.8 KiB
Plaintext
Build Open Agila and grow its developer community
|
|
|
|
Objective
|
|
Develop Open Agila into a reproducibly buildable, open operating system, primarily in Ada and V. Use OpenStep as an application-framework reference and MINIX as a reference for a small kernel, explicit IPC, least authority, and restartable services. Inspect the specific Open Amiga repository supplied by the owner before deciding what to integrate. Do not substitute AROS or a different Amiga project without that evidence.
|
|
|
|
Begin with the existing Agila Forge repositories and preserve their history, licenses, and working behavior. Keep Open Agila development distinct from private Agila OS components. Do not publish private source, credentials, or unexplained third-party binaries. Keep Flying V distinct from standard V and use its actual compiler/SDK contracts.
|
|
|
|
Build in verifiable milestones
|
|
1. Audit current code and publish an architecture, source inventory, supported-target matrix, and backlog with testable acceptance criteria.
|
|
2. Make the existing host build repeatable. Implement a bounded Ada message-port core, explicit access checks, and a V client through a documented ABI. Test errors, capacity limits, stale handles, and invalid requests as well as successful behavior.
|
|
3. Produce a minimal x86-64 QEMU boot target with serial output and a bounded smoke test. Clearly distinguish bare-metal boot evidence from host simulations.
|
|
4. Progress toward memory management, exception/interrupt handling, scheduling, separate address spaces, IPC syscalls, restartable user services, storage, networking, and device drivers. State what is implemented, simulated, untested, or planned. Add real isolation tests before describing a service as isolated.
|
|
5. Build the application/runtime layer and OpenStep-informed framework contracts in Ada and V/Flying V. Develop compatibility only against an identified specification and executable conformance tests. Integrate the owner's Open Amiga source only after reviewing its APIs, provenance, and license.
|
|
6. Add CPU/GPU topology, memory mappings, synchronization, and measured workload placement as hardware support becomes available. Label simulated measurements and untested hardware honestly.
|
|
|
|
Expand Agila Forge
|
|
Publish working source, build instructions, examples, tests, architecture decisions, and contribution guides. Organize real starter tasks and larger milestones with acceptance criteria. Make it easy for a new developer to clone, build, reproduce a test, submit a patch, and explain the result. Preserve the restored repositories and hosting protections. Do not enable execution of untrusted CI jobs on the production Forge host.
|
|
|
|
Expand Agila University
|
|
Turn each verified implementation milestone into English, Tagalog, and Bisaya lessons of approximately 15 minutes, with runnable browser exercises where supported, automated checks, feedback, and links to the exact source. Retain lesson and track completion certificates. Connect learning tracks to projects and real Forge contributions. A certificate records completed checks; tested code, explanations, documentation, and portfolio work provide additional evidence of skill. No human mentor is required for lesson progression.
|
|
|
|
Definition of progress
|
|
Report exact commits, reproducible commands, test results, supported targets, and remaining work. Do not call a host prototype a bootable OS, a boot demo a complete operating system, or a model a measured hardware result. Avoid promises of full compatibility or professional mastery without evidence. Continue useful independent work while a specific integration detail is awaiting clarification.
|
|
|
|
Long-term success
|
|
A growing pool of developers can independently understand, test, maintain, and extend Open Agila: applications, websites, server systems, OS components, and AI runtimes. Judge success through working contributions and understanding, including the ability to review AI-generated code.
|