We welcome contributions from everyone. However, please follow the following guidelines when posting a GitHub Pull Request or filing a GitHub Issue on the systemd project:
Following these guidelines makes it easier for us to process your issue, and ensures we won’t close your issue right-away for being misfiled.
For older versions that are still supported by your distribution please use respective downstream tracker:
LGPL-2.1-or-later. If the license is not
LGPL-2.1-or-later, please add a note to
After performing a review, set
reviewed/needs-reworkif the pull request needs significant changes
ci-fails/needs-reworkif the automatic tests fail and the failure is relevant to the pull request
ci-failure-appears-unrelatedif the test failures seem irrelevant
needs-rebaseif the pull request needs a rebase because of conflicts
good-to-merge/waiting-for-ciif the pull request should be merged without further review
good-to-merge/with-minor-suggestionsif the pull request should be merged after an update without going through another round of reviews
Unfortunately only members of the
systemd organization on github can change labels.
If your pull request is mislabeled, make a comment in the pull request and somebody will fix it.
Reviews from non-members are still welcome.
We’d like to apologize in advance if we are not able to process and reply to your issue or PR right-away. We have a lot of work to do, but we are trying our best!
Thank you very much for your contributions!
We strive to keep backward compatibility where possible and reasonable. The following are general guidelines, not hard rules, and case-by-case exceptions might be applied at the discretion of the maintainers. The current set of build-time and runtime dependencies are documented in the README.
It is fine for new features/functionality/tools/daemons to require bleeding edge external dependencies, provided there
are runtime and build-time graceful fallbacks (e.g.: a daemon will not be built, runtime functionality will be skipped with a clear log message).
In case a new feature is added to both
systemd and one of its dependencies, we expect the corresponding feature code to
be merged upstream in the dependency before accepting our side of the implementation.
Making use of new kernel syscalls can be achieved through compat wrappers in our tree (see:
and does not need to wait for glibc support.
It is often tempting to bump external dependencies’ minimum versions to cut cruft, and in general it’s an essential part of the maintenance process. But as a general rule, existing dependencies should not be bumped without strong reasons. When possible, we try to keep compatibility with the most recent LTS releases of each mainstream distribution for optional components, and with all currently maintained (i.e.: not EOL) LTS releases for core components. When in doubt, ask before committing time to work on contributions if it’s not clear that cutting support would be obviously acceptable.
Same principles as with other dependencies should be applied. It is fine to require newer kernel versions for additional functionality or optional features, but very strong reasons should be required for breaking compatibility for existing functionality, especially for core components. It is not uncommon, for example, for embedded systems to be stuck on older kernel versions due to hardware requirements, so do not assume everybody is running with latest and greatest at all times. In general, currently maintained LTS branches should keep being supported for existing functionality.
libsystemd.so is a shared public library, so breaking ABI/API compatibility would create lot of work for everyone, and is not allowed. Instead, always add a new interface instead of modifying
the signature of an existing function. It is fine to mark an interface as deprecated to gently nudge users toward a newer one,
but support for the old one must be maintained.
Symbol versioning and the compiler’s deprecated attribute should be used when managing the lifetime of a public interface.
libudev.so is a shared public library, and is still maintained, but should not gain new symbols at this point.