Version 14 (modified by Martin Decky, 12 years ago) ( diff )

add link

How to contribute

We welcome any effort to make HelenOS a better operating system. Here are some tips on what to do when you feel like contributing code. Make sure you subscribe to HelenOS-devel mailing list so that you can communicate efficiently with us.

Ideas to work on

First of all, you need to know what to contribute or what to do. If you don't have your own idea, we provide you with the following options:

  • pick any open ticket; these include everything from above plus everything else (e.g. bugs, suggestions, enhancements on which the project progress depends)

We encourage you to file new tickets if you think that your great idea is missing on the list, but please do discuss the issue with us on the mailing list.

When you found or created a ticket that you would like to work on, make sure it is not owned by someone else. If the ticket is available, feel free to assign it to yourself. Otherwise you may want to ping the ticket owner on our mailing list to see if he or she is really working on the ticket. It can happen that the owner will gladly agree to pass the ticket ownership onto you.

Working on your branch

Now that you know what to do, you should go and create your private Bazaar branch of HelenOS. This is essential so that we can later merge your changes together with your initials in the development history of the branch. During the coding phase, keep in mind that we will require your changes to meet our coding style standards. It will happen to you from time to time that you will need to consult something with the other people from the project. Don't be shy and feel free to discuss things with us either in the mailing list or on IRC. For example, you can create a merge directive in Bazaar and send it to the mailing list for code review. Make smaller, logically related changesets rather than one huge changeset. Make sure that each changeset is accompanied by a clear commit message in English.

Submitting patches

If you have a simple change that you would like us to push to the mainline, you can submit it in the form of a patch. To submit your work as a patch, please follow these rules:

  • Always use unified diff format (bzr diff, diff -u)
  • Always send the patch to HelenOS-devel
  • Specifically, do not just attach the patch to a ticket as most developers won't be made aware of it
  • Send the patch as an attachment. Inline patches will get broken by the MTAs.
  • Choose a Bazaar identity and include it in the message so we can correctly attribute you with --author. This is important as not everybody wants their real e-mail address to appear in the commit log.

Alternatively you can provide us with a pointer to a public Bazaar branch (e.g. on Launchpad) from where we can pick the changes. In case you maintain a local branch with your changes and don't want to publish it, we can still merge from it using a Bazaar merge directive. A merge directive can be viewed as a better text patch which carries all the history and change information of your local branch while still being human readable. Once your local branch is ready to be merged, the merge directive can be created as follows:

$ bzr send -o my_merge.directive

Then send a brief message describing the change to our mailing list and attach my_merge.directive to it.

Compiling the system

Once you have your Bazaar branch ready you will want to compile the system so that you can test your changes. There are some common mistakes people make when trying to compile HelenOS so please read the compiling instructions carefully before running to us claiming that HelenOS does not build or does not work.

Integrating your changes

When you have tested your changes carefully and are confident enough that there are no bugs, you can ask one of us to merge your changes to our official repository. For that, you need to do one of two things. Either send us your final Bazaar merge directive or publish your branch in a publicly accessible location (e.g. Launchpad) so that we can merge from there. Note that publishing your branch is a good idea anyway because others can see your progress and your changes are backed up. Eventually, if your changes look good to us, we will merge them and you will become part of the history.

Note: See TracWiki for help on using the wiki.