Thanks for considering contributing to Ironclad, it means a lot.
There are several ways one can help the Ironclad project, from writing and correcting documentation to contributing source code. A great way to help Ironclad as well is sharing it with people that may find it interesting!
For all of Ironclad's projects, like ironclad itself, this website, and util-ironclad,
open tasks, along with their progress, effort required, and priority,
are tracked on the
Savannah task manager
(Submit a new item).
Feel free to read the available items to give input, take the lead and
contribute, or submit your own items.
For testing changes to Ironclad itself, one will need a system running Ironclad. Our recommendation is using Gloire in a virtual machine or real hardware to test modifications. For a guide on how to modify Gloire's Ironclad, building images with custom kernels, and testing them, please check this article.
One can send a patch to any of the Ironclad's Patch Manager (create an item) or the project's mailing lists as well.
When submitting contributions, only contributions licensed under the GPL, or alternatively, a GPL-compatible license, will be accepted.
In order to ensure this is the case, submitted patches will need to
certify their work by accepting the project's
Developer Certificate of Origin (DCO).
This is done by either adding Signed-off-by to the patch,
either manually or using git's -s flag, or by stating
compliance in the patch submission.
DCOs do no copyright assignment, and the contributor keeps each and every right over their contribution. Individual contributor copyright is one of the core pillars of free software. This process only gives a bit of legal shielding for the project if that is not the case.
Reproducible builds enable anyone to reproduce bit by bit identical binary packages from a given source, so that anyone can verify that a given binary derived from the source it was said to be derived. There is more information about reproducible builds on the Debian wiki and on https://reproducible-builds.org. These pages explain in more depth why this is useful, what common issues exist and which workarounds and solutions are known.
We try to apply these principles to Ironclad. We periodically
check ironclad master branch and each release tarball
before releasing for variations using
reprotest.
Here are listed the expected variables that will change build output, if they remain constant, Ironclad builds will be reproducible.
| Variable | Reason |
|---|---|
| Compiler/linker versions | Generated code will change |
| gprbuild/gnatmake versions | Different tooling versions may change flags |
| OS directory listing order | gprbuild/gnatmake use OS directory listing order to fetch source directory contents for compilation and linking, which makes them a compilation variable. Hopefully, that gets fixed soon. |
Ironclad has several mailing lists and official servers and services for users as well as developers to talk with each other and coordinate, feel free to check them out at the community page.
A kernel is really dependent on its user programs. Here is a list of projects that are a great option to get involved with, without having to do kernel development: