Development
If you want to get started with development, you need to think about whether you want to build the latest stable release, or whether you want to build the latest development code. The build instructions evolve over time and it's important you follow the instructions matching the code you're building. If you wish to contribute, following the latest development code is desirable.
Source Code
You can retrieve the current git master from our gitlab project page.
You can find the source for the latest release in the sortix-1.0 tag or
the current development source code in the master branch.
You can download release source code tarballs from your release mirror.
Build Instructions
If you want to build the stable release, the development(7) manual page describes development from inside a release. The cross-development(7) manual page describes developing from another operating system using cross-compilation.
If you want to build the latest development code, you need to instead follow the manual pages in the source code (which are uploaded to the online nightly manual every night): the share/man/man7/development.7 manual page describes development from inside a release. The share/man/man7/cross-development.7 manual page describes developing from another operating system using cross-compilation. share/man/man7/following-development.7 contains instructions for how to stay up to date with breaking changes in the latest source code. You can view these manual pages by giving their path (containing at least one slash) as parameter to the man command.
Nightly Builds
Cutting edge Sortix is built from the latest development code every night on the previous night's Sortix release. These are better basis for development than latest release as it contains the current master branch source code. It is possible to upgrade an existing installation to a newer version. Downgrading is not supported.
- pub.sortix.org (Germany)
- ahti.space (US)
See the latest installation(7) and upgrade(7) pages in the nightly manual.
The regular 'nightly' build is made from the git master branch and are linked to above for your convenience. The 'volatile' build is made from the staging branch, the lead developer's personal experimental branch you should have no need to touch unless you were told to test something bleeding edge. The volatile build is absent from the above links for your convenience. Look to the parent directory to download other releases.
Participation
You can participate in the Sortix community by testing the system, publicly showing interest by hanging in the IRC channel, blogging about it, writing documentation, finding mistakes in it, or perhaps by developing the system.
The fastest way to get started with development is to install the latest
release, tinker around with the system, find an itch to scratch, fix the issue
in /src using all the included development tools,
extract a patch, and file a pull request at
the issue tracker.
If you are willing to invest a little time in building your own cross-compilation toolchain and you prefer developing from another operating system, you can do so by following the cross-development(7) manual page.
Development is coordinated in the #sortix IRC channel at irc.sortix.org self-hosted on a Sortix server.
Bugs are managed using the issue tracker.
Submitting Patches
If you have a good idea, find a bug, a documentation error, or even just a typo or bad indention, it's sufficient to just show up and say so, or even open an issue in the issue tracker. It'll be noted down and fixed in its own time without any more action on your part.
But you're more than welcome to take matters in your own hands and contribute commits:
The first step should be to show up in the #sortix IRC channel and coordinate
your changes with sortie. He might not always be around, but you can type
#msg sortie I'd like to contribute X to sortix. which gets to delivered next
time he logs on. Alternatively you can send an email. Early and clear
communication helps sanity check your proposals and whether they're a suitable
first project and even whether your proposal is even suitable for Sortix.
After discussing the issue, it'll probably make sense to open an issue on the issue tracker if there isn't any already.
You can fork the Sortix project on gitlab. It's not possible for other people to have their own branches in the official repository. You can submit a merge request on gitlab pointing to your git repository. Alternatively, you can use git format-patch and upload the patch somewhere or send it by email.
Code review is mandatory. Commits will not be merged until they are as good as possible. Expect your commit to be discussed and style issues to be nitpicked until it's perfect. You will need to follow the coding convention, which is not written down at the moment. Follow nearby code when in doubt. You will need to update any documentation as well if you update something which is documented. If you contribute new programs (there currently is an exception for features and programs that are standard in other operating systems), you will need to document them with manual pages as well. Manual pages are written in the mdoc(7) format.
Your git commit author string should contain your real name and email address to make it certain who owns the copyright but pseudonyms are allowed. Your commits should be rebased on the master branch so they can be merged with a fast-forward merge.
You will be required on your first contribution to state that your Sortix contributions are licensed under the ISC license (as the rest of Sortix).
These practices are not final. You help shape the project and the development processes.
Perks
Contributors to the Sortix project can get voice in the #sortix channel and get a special Sortix cloak. Their code contributions will also be thanked in release announcements. Code contributors can get reporter status on the Sortix gitlab project.
Ports Collection
Sortix has a collection of 80+ pieces of ported third party software. These ports are maintained as build instructions with links to the upstream tarballs plus local patches checked into the ports directory in the source code. All ports can built natively and cross-compiled.
If the patches are operating system agnostic and make sense upstream, and are still applicable to the latest upstream release, you can help out by submitting changes to their project. config.sub changes can be upstreamed by telling projects to use the latest config.sub and config.guess files from the GNU config project as the upstream files knows about Sortix.