Getting Started
From eyeOS Developers Wiki
Contents |
[edit] eyeOS Code
The eyeOS code is divided in four parts: applications, libraries, services and the kernel. The first three categories have also sub-categories (one for each application, library or service), and each one of them has its mantainer, which can be either a team or a single developer.
[edit] Control Version System
[edit] Access
The anonymous access to the repository is only enabled for reading. To be granted total access to it, you must send a mail to eyeos-dev@eyeos.org indicating the name of your SourceForge account. You must bear in mind that the fact of having total access to the repository does NOT enable you to modify any part of the system you want.
[edit] Permissions
You cannot commit a change in a part you are not a maintainer of. In case of needing such a change, you must use the mailist to request permission of the part's maintainer. In case that you don't know who is the mantainer, just send a mail to the devel mailist asking for it.
[edit] Structure
The structure used is similar to that recommended in Subversion:
trunk/ Branch where the development of eyeOS is focused. tags/ Directory in which the code of each released version is freezed. branches/ Directory in which all branches of eyeOS or its parts are stored. unstable/ Branch where new applications or unstable changes are made.
[edit] Committing
There are a series of good habits that must be accomplished to ensure a correct functioning of the repository:
Before commiting a change, you should update your code to the last revision and check it works flawlessly. You must think the possible consequences of your changes. In case of doubt, you must consult in the mailing list. You cannot commit a change in a part mantained by other people before consulting them before. The commits must always be related to the purpose of the changes. You cannot commit different changes with different purposes.
Remember that every commit must have a comment, indicating what modify/add and the propose of this change.
Finally, we have a few tags to indicate what is the reason of the commit:
- [FIX] or [FIX #000000]: This tag is to mark that the commit is to fix a bug. If the bug are reported in the bugtrack (launchpad) the bug id must be attached).
- [FEATURE]: When we finish the implementation of the new feature, we need to indicate it with this tag (only in the final commit when the feature is considered stable).
- [SECURITY]: If the commit fix a security bug, it need to be tagged with a special tag. Only the bugs considered as security bug by the eyeOS security team (security@eyeos.org) are accepted.
[edit] Fixing Bugs
When a bug is fixed, you must indicate in the comment of the commit an identifying number, accompanied by a precise explanation of the problem and solution. For example:
BUG: #189203 eyeOS Don't have a platform for help the developers feedback.
Now, we use launchpad as developers platform.
[edit] Sending a patch
If you have a patch that fix/add some feature to eyeOS, you need to send an email to the eyeos-patch mailist to be able to discuss about it with the maintainer of the part that you patch modify. In this thread inside the mailist, the patch will be discussed and accepted if it is correct. Then if you have commit access you'll able to commit it yourself.
[edit] Mailing list
The eyeOS mailing lists are thought for the communication between developers, and they have a technical profile:
- eyeos-bugs: discussion about possible bugs encountered.
- eyeos-patchs: reporting of patches waiting for its approval.
- eyeos-devel: discussions around eyeOS development.
- eyeos-security: discussions about the security of eyeOS.
To read a bit more about mailist click here
[edit] Launchpad
The services of bug and ideas reporting are delegated to Launchpad. The decision of hosting these services in Launchpad is based on the friendliness of the platform with the novice users, which provides the project much more feedback with its users.
A bit more about launchpad usage:
