RedBear-OS/CONTRIBUTING.md

Contributing to Red Bear OS

Thank you for your interest in contributing to Red Bear OS!

This document will outline the basics of where to start if you wish to contribute to the project. There are many ways to help us out and and we appreciate all of them. We look forward to your contribution!

Please read this document until the end

Code Of Conduct

We follow the Rust Code Of Conduct.

License

In general, your contributions to Red Bear OS are governed by the MIT License. Each project repository has a LICENSE file that provides the license terms for that project.

Please review the LICENSE file for the project you are contributing to.

This page we explain why we use the MIT license.

Contribution Terms

When making a contribution you agree to the following terms:

• I understand these changes in full and will be able to respond to review comments.
• I have read the Developer Certificate of Origin and certify my contribution under its conditions.

AI Policy

We welcome contributions made with the assistance of LLMs and AI tools. We care about the quality of the result, not how it was produced.

Chat

You can join in our chat platforms to discuss development, issues or ask questions.

Matrix

Matrix is the official way to talk with the Red Bear OS team and community (these rooms are English-only, we don't accept other languages because we don't understand them).

Matrix has several different clients. Element is a commonly used choice, it works on web browsers, Linux, MacOSX, Windows, Android and iOS.

If you have problems with Element, try Fractal.

• Join the Join Requests room and send a message requesting for an invite to the Redox Matrix space (the purpose of this is to avoid spam and bots).
• #redox-join:matrix.org (Use this Matrix room address if you don't want to use the external Matrix link)

(We recommend that you leave the "Join Requests" room after your entry on the Red Bear OS space)

If you want to have a big discussion in our rooms, you should use a Element thread, it's more organized and easy to keep track if more discussions happen on the same room.

You cand find more information on the Chat page.

Discord

We have a Discord server as an alternative for Matrix, open the #join-requests channel and send a message requesting to be a member (the purpose of this is to avoid spam and bots)

The Matrix messages are sent to Discord and vice-versa using a bot, but sometimes some Discord messages aren't sent to Matrix (if this happens to you join in our Matrix space above)

GitLab

A slightly more formal way of communication with fellow Red Bear OS developers, but a little less quick and convenient like the chat. Submit an issue when you run into problems compiling or testing. Issues can also be used if you would like to discuss a certain topic: be it features, code style, code inconsistencies, minor changes and fixes, etc.

If you want to create an account, read the Signing in to GitLab page.

Once you create an issue don't forget to post the link on the Dev or Support rooms of the chat, because the GitLab email notifications have distractions (service messages or spam) and most developers don't left their GitLab pages open to receive desktop notifications from the web browser (which require a custom setting to receive issue notifications).

By doing this you help us to pay attention to your issues and avoid them to be accidentally forgotten.

If you have ready MRs (merge requests) you must send the links in the MRs room. To join this room, you will need to request an invite in the Join Requests room.

By sending a message in the room, your MR will not be forgotten or accumulate conflicts.

Best Practices and Guidelines

You can read the best practices and guidelines on the Best practices and guidelines chapter.

Repository Model for Contributors

RedBearOS should be treated as an full fork on top of Redox, in the same way Ubuntu relates to Debian.

That means contributors should keep this separation in mind:

• upstream-owned trees such as recipes/*/source/ are immutable archived release snapshot,
• durable Red Bear-specific work belongs in local/patches/, local/recipes/, local/docs/, and tracked Red Bear configs,
• if a change exists only in an upstream-owned source tree, it is not yet preserved properly for long-term Red Bear maintenance.

WIP rule for contributors

If an upstream recipe or subsystem is still marked WIP, Red Bear treats it as a local project until upstream promotes it to first-class status.

So for contributors:

• upstream WIP may still be a useful input/reference,
• but fixes intended for Red Bear shipping should normally land in the Red Bear release fork,
• and when upstream later catches up, Red Bear should prefer upstream and retire local patches or local recipe copies that are no longer needed.

Development Recommendations and Tips

• Copy-paste prevent and reduce typos
• Comment out configuration or code while testing is better than removal, to remember the testing conditions and prevent mistakes from forgotten logic
• Read the entire Build System Reference and Developer FAQ pages
• Make sure your build system is up-to-date, read the Update The Build System section if in doubt.
• If you want to make local changes in recipe sources it's recommended to automatic recipe source update, read this section to learn how to this for one or multiple recipes and this section for all recipes.
• If you want to make changes to system components, drivers or RedoxFS you need to manually update initfs, read this section to learn how to do that.
• If some program can't build or work, something can be missing/hiding on relibc, like a POSIX/Linux function or bug.
• If you have some error on QEMU remember to test different settings or verify your operating system (Pop_OS!, Ubuntu, Debian and Fedora are the recommend Linux distributions to do testing/development for Red Bear OS).
• Remember to log all errors, you can use the following command as example:

your-command 2>&1 | tee file-name.log

• If you have a problem that seems to not have a solution, think on simple/stupid things. Sometimes you are very confident on your method and forget obvious things (very common).
• If you want a quick review of your Merge Request, make it small.
• If your big Merge Request is taking too long to be reviewed and merged try to split it in small MRs. But make sure it don't break anything, if this method break your changes, don't shrink.

Style Guidelines

Rust

Since Rust is a relatively small and new language compared to others like C and C++, there's really only one standard. Just follow the official Rust standards for formatting, and maybe run rustfmt on your changes, until we setup the CI system to do it automatically.

Git

Please follow our Git style for pull requests.

For user-visible work, keep the root CHANGELOG.md current and immutable archived the README "What's New" section with the latest highlights so GitHub visitors can immediately see what changed.

When a commit changes the visible system surface, supported hardware, build flow, shipped configs, or key docs, add a short user-facing changelog note in the same change.

GitLab

Identity

Once your GitLab account is created, you should add your Matrix or Discord username (the name after the @ symbol) on the "About" section of your profile, that way we recognize you properly.

Issues

We use issues to organize and track our current and pending work, to know how to create issues on the Redox GitLab read the Filing Issues page.

Once you create an issue don't forget to post the link on the Dev or Support rooms of the chat, because the GitLab email notifications have distractions (service messages or spam) and most developers don't left their GitLab pages open to receive desktop notifications from the web browser (which require a custom setting to receive issue notifications).

By doing this you help us to pay attention to your issues and avoid them to be accidentally forgotten.

You can see all issues on this link.

Pull Requests

Please follow our process for creating proper pull requests.

Important Places to Contribute

Before starting to contribute, we recommend reading the General FAQ and the Redox Book.

You can contribute to the Red Bear OS documentation and code on the following repositories (non-exhaustive, easiest-to-hardest order):

• Website
• Book - High-level documentation
• Build System Configuration - Our main repository
• pkgutils - Package Manager
• acid - Redox Test Suite
• relibc - Redox C Library
• libredox - Redox System Library
• Bootloader
• RedoxFS - Default filesystem
• Base - Essential system components and drivers
• Kernel

To see all Redox repositories open the redox-os group.

Skill Levels

If you don't know programming:

• Test the daily images on your computer and add the report on the Hardware Compatibility list
• Monitor and warn developers if the daily images are outdated
• Use/test Redox and create issues for bugs or needed features (please check for duplicates first)
• Fix and write documentation
• Find or fix typos in configuration

If you don't know how to code in Rust but know other programming languages:

• Web development on the website (we only accept minimal JavaScript code to preserve performance)
• Write unit tests (may require minimal knowledge of Rust)
• Port C/C++ programs to Redox (read upstream WIP TODOs as inputs, but do not assume upstream WIP recipes are automatically the durable Red Bear shipping source of truth)
• Port programs to Redox

If you know how to code in Rust but don't know operating system development:

• See the easy issues
• See the "good first issue" issues
• See the help wanted issues (it's worth noting the skill level varies between projects, but a large subset of these should be approachable by contributors familiar with regular Rust/Unix application programming)
• Improve the package manager, or build system tooling like redoxer or installer
• Improve the Ion shell, or other high-level or mid-level projects
• Port Rust programs (also look for issues with the port label)
• Improve application compatibility in relibc by e.g. implementing missing POSIX/Linux functions

If you know how to code in Rust, and have experience with systems software/OS development:

• Familiarize yourself with the repository layout, code, and build system
• Update old code to remove warnings
• Search for TODO, FIXME, BUG, UNOPTIMIZED, REWRITEME, DOCME, and PRETTYFYME and fix the code you find
• Look in general for issues with the following labels: critical, help wanted, feature, enhancement, bug or port
• Improve internal libraries and abstractions, e.g. libredox, redox-scheme, redox-event etc.
• Help upstream Redox-specific functionality to the Rust ecosystem
• Improve Redox's automated testing suite and continuous integration testing processes
• Improve, profile, and optimize code, especially in the kernel, filesystem, and network stack
• Improve or write device drivers

For those who want to contribute to the Redox GUI, our GUI strategy has changed.

• We are concentrating current forward desktop work on the KWin Wayland path in the main build-system repository.
• Legacy GUI toolkit efforts are in maintenance mode, and there is currently no separate Redox-specific GUI toolkit effort underway.

Priorities

You can use the following GitLab issue label filters to know our development priorities on the moment:

• Critical
• High-priority
• Medium-priority
• Low-priority

Roadmap

We use tracking issues for the goals in our roadmap, you can see them in the filter below:

• Tracking issues

RFCs

For more significant changes that affect Redox's architecture, we use the Request for Comments repository.

Build System

To download the build system use the following commands:

(You need to have curl installed on your system)

curl -sf https://gitlab.redox-os.org/redox-os/redox/raw/master/podman_bootstrap.sh -o podman_bootstrap.sh

time bash -e podman_bootstrap.sh

To start the compilation of the default recipes run the command below:

make all

In case your operating system does not use SELinux, you must set the USE_SELINUX to 0 when calling make all, otherwise you might experience errors:

make all USE_SELINUX=0

You can find the build system organization and commands on the Build System page.

Developer FAQ

You can see the most common questions and problems on the Developer FAQ page.

Porting Software

You can read how to use the Cookbook recipe system to port applications on the Application Porting page.

Always verify if a recipe for your program or library already exist before porting to not break the build system with a recipe duplication or waste time.

Libraries and APIs

You can read the Libraries and APIs page to learn about the libraries and APIs used in Redox.

Visual Studio Code (VS Code) Configuration

To learn how to configure your VS Code to do Redox development please read the information below the Visual Studio Code Configuration section.

References

We maintain a list of wikis, articles and videos to learn Rust, OS development and computer science on the References page.

If you are skilled/experienced there's still a possibility that they could improve your knowledge in some way.

Other Ways to Contribute

If you aren't good on coding, but you still want to help keep the project going, you can contribute and support in a variety of ways! We'll try to find a way to use anything you have to offer.

Design

If you're a good designer, whether it's 2D graphics, 3D graphics, interfaces, web design, you can help. We need logos, UI design, UI skins, app icons, desktop backgrounds, etc.

• Redox backgrounds - You can send your wallpapers on this repository.
• Redox assets - You can send your logos, icons and themes on this repository.

If you have questions about the graphic design, ask us on the Chat.

Donate

If you are interested in donating to the upstream Redox OS project, you can find instructions on the Donate page.