[WARNINGS] link-id not found - [fmiosacomparativestudypartikernellandchapter1bootup|1 link-id not found - [fmiosacomparativestudypartikernellandchapter3scheduling|3 link-id not found - [fmiosacomparativestudypartikernellandchapter5memorymanagement|5 link-id not found - [fmiosacomparativestudypartikernellandchapter7deadlocks|7 link-id not found - [fmiosacomparativestudypartiiuserlandchapter8iolayers|8 link-id not found - [fmiosacomparativestudypartiiuserlandchapter10environmentlayer|10
Intro (I 1 2 3 4 5 6 7) (II 8 9 10 11) (D) (C) (B
I)
h1. Part III: Open Source Development
FMI/OS is being developed as open source, under the GPL (General Public License). What this means is that its source code can be read, and modified, by anyone, as long as the original authors are credited and all changes are documented. The idea is that by extending the availability of design and code documents, we would be broadening our access to more new and creative innovations without being restricted to developers that required financial reimbursement.
Not only does this provide for the potential of better, tighter, and more efficient programs, it also makes the art and science of computer programming more accessible to the common people. For those that do not want to, or can't, contribute to the actual writing of the program, they can still have access to, and learn from, the source code.
To learn more about the open-source and "Free is for Freedom" movement, see the GNU home page (see GNU in the Bibliography). They are one of the forerunners, as well as the creators, of the GPL.
h2. 1. Communication
When working on a project together, communication among the developers is key. This ensures that everyone is on the same wavelength and that code and concepts remain compatible and all work is towards a common goal. The FMI/OS development team is scattered throughout the world: USA, Germany, UK, Finland, and Sweden. They remain in contact via three means:
=== IRC Channel ===
Perhaps the single most common and important form of communication is done on an IRC (Internet-Relay Chat; a chat-room-like protocol) channel. The two channels most commonly used are @#fmios@ and @#ocgnet@ on the irc.freenode.net IRC server. On these channels all developers can log on and talk to one another in a public forum where anyone can read all messages. Rarely are conversations about the project made outside of this common "room" because any and all discussions are logged and could benefit other current, and future, developers.
=== FMI/OS Homepage ===
As a center of operations, the FMI/OS homepage offers a place to house news, archives, logs, and other developments. The homepage also provides a wiki interface. A wiki is a webpage that can be edited by anyone who can browse it. For example, since this thesis is on the wiki, I can edit it by logging in, going to the page that contains the chapter I want to work on, and clicking the 'edit' button. An editor window comes up which allows me to edit the text directly online. Anyone with an account can do this, as well. Although it is unlikely that anyone with an account has any malicious intent, were they to edit any of the thesis, there are still ways of tracking changes made to the page and revoking any unnecessary changes.
The use of the Trac wiki system provides a slew of useful tools. Any large-scale software development project requires a structured set of goals as well as issues that need be resolved. Trac provides a [trac:Roadmap Roadmap] to track issues (called tickets) and plot the goals of major steps (called Milestones) along the way to completion.
=== Source tree ===
The final means of communication is through the source tree, itself. This is where the source code for the project is stored. This is discussed in the next section.
h2. 2. Coding/Submission
The source code is currently available on the website and anyone can find more information on downloading and installing it by reading the page on Getting The Source. Someone could also use an SCM (Source Code Manager) such as @bzr@ to download the full source tree from other developers.
To prevent developers from stepping on each others' toes, each volunteer is assigned to certain tasks, which are called tickets on Trac. Each developer is responsible for working on, and submitting patches solely for, that specific ticket. Typically, working on these issues takes a lot of work, so developers have their own branches of the source code that they work on and test, independent of the primary (stable) branch.
As developers fix bugs or solve issues inside the source they can apply their fixes as patches to the main, working, stable branch of the source code. The concept of organizing, testing, and approving these patches is patch-queue management, or pqm. Once they pass the pqm process, patches are sent to the SCM. The job of the SCM is to merge a patch into the source code, line by line.
Here's an overview of the process:
- A developer works on his prescribed issue on his private development branch of the source code.
- Once the developer has accomplished his task, he documents all of the necessary changes needed to the source code.
- These changes, also called diffs, are what make up the actual patch.
- The developer sends the patch to the system handling the pqm process.
- The patch is actually an attachment to a pgp-signed e-mail, addressed to the pqm system.
- Patches are sorted chronologically into a queue.
- Each patch is applied to a copy of the stable branch for testing
- A thorough automated test is conducted on the test source: bootup, message-passing, multiple users, I/O, successive & recursive filesystem scans and accesses, etc.
- If any part of the test fails the patch is rejected and the developer who submitted the patch is notified of the specifics of the failed test.
- Successfully tested patches are put to a democratic voting process for submission to the SCM.
- Voting can be made by all users and developers.
- Primary developers have over-riding vetoes on all voted decisions (in case a patch may compromise future development plans)
- Any patch that is approved will then be submitted to the SCM for assimilation into the final, stable source code.
- The SCM reads the diffs in the patch and changes the source code appropriately.
The stable branch is the primary branch for users and new developers to download from the website or from the SCM. In addition, when someone is working on an issue on their own branch, they can choose to solicit the location of their branch (“publish” it) to the SCM or to other developers to allow them to download and experiment with it.
(c)2006 Dimitri Hammond