Philippe Gerum
|
How To Contribute
If you are interested in contributing to Xenomai here are some helpful hints on how to get started. Start small, then progress as you get your feet wet. There is no such thing as a minor contribution, there is no shame in making mistakes. A contributor who submits a perfectible one-liner surely advances the project further than any smart lurker.
Things you will need:
-
Git
-
GCC for your platform
-
Xenomai source code
-
Linux tree patched with the I-pipe
-
Autotools
-
Access to the Xenomai mailing list
Workflow
The above mentioned documents will guide you through acquiring the source code, getting the development environment set up, and building Xenomai. If you are having issues getting your development environment setup or built, please review the documents or consult the Xenomai mailing list.
Next, check the current contribution guide in the code repository. It comes with a checklist you should run through prior to posting your change, and it also explains what happens with it after you submitted it to the list.
As a guideline for what branch to work on, the master branch is for new core features, new CPU architecture ports or large scale changes. Only bug fixes and possibly new drivers should be pushed to stable/* branches. Any change that would prevent applications based on earlier releases from the same branch from running on later ones should not go into stable/* branches. For example, an application built for the 3.0.2 release must build with no modifications on 3.0.6.
Generally speaking, the kernel part of Xenomai (aka Cobalt core) aims at following the standard kernel coding style.
After you make your changes, one thing to keep in mind is that when you submit your patches to the the mailing list each patch should address exactly one issue. You may want to make one commit for every patch you wish to generate. This may be a good workflow if you are addressing more than one issue during development.
When you are done development and testing you are ready to generate patches. Use git format-patch to create a patch (or patch set) that you can submit for review.
Once you have generated your patch (or patches) you need to send them off to the mailing list for review. This can be done using git send-email. This may be slightly tricky to set up. I suggest googling for the best way to set this up in your gitconfig file that best suits your email provider and authentication method. Once it is configured you can submit your patch to the mailing list.