Back to systemd


The upstream systemd git repo only contains the main systemd branch that progresses at a quick pace, continuously bringing both bugfixes and new features. Distributions usually prefer basing their releases on stabilized versions branched off from this, that receive the bugfixes but not the features.

Since distributions have different release cycles and thus base their releases on different systemd versions we do not provide stable release branches upstream. However, we tag our commits to indicate when we believe they are relevant for backporting.

Moreover the systemd community maintains a stabilized systemd "stable" tree in an independent repository that branches from time to time on the newest releases.

Commits Tagged for Backporting

Commits we recommend for backporting to stable branches are tagged with the git notes feature.

These notes are stored within the main development repository. To get access to them you need to pull them explicitly into your checkout:

$ git fetch origin refs/notes/*:refs/notes/*

If you intend to do this regularly, it probably makes sense to add notes to the list of refs to fetch:

$ git config --add remote.origin.fetch '+refs/notes/*:refs/notes/*'

Afterwards they will be shown next to the commit message in the "git log" output.

They are also shown as yellow dots in gitk.

Alternatively you can actually browse the notes with cgit, but it's not fun. Here's an example for a commit with a backport tag:

The following notes are currently used:

Backport: security
Backport: bugfix
Backport: performance
Backport: documentation

"Backport: security" indicates commits that are relevant bugfixes that close security holes. "Backport: bugfix" indicates other fixes for important bugs. "Backport: performance" indicates bugs that improve performance of certain operations under certain conditions in majors ways, that are relevant enough to make them relevant for backporting. "Backport: documentation" indicates corrections to documentation or text strings.

Adding Backport Commits

If you'd like to see a commit tagged for backporting and do not have commit privileges, please contact a developer and ask them to add the tag.

If you are a developer with commit access please tag your commits following this scheme. For this use "git notes add " to add a note:

$ git notes add da2620a5f878ad5c8d8d51992528cb3e637c7d1f -m 'Backport: TYPE'

Then, push the notes to the server:

$ git push origin refs/notes/*

This is much nicer with a macro:

$ git config alias.pushnotes 'push origin refs/notes/*'
$ git pushnotes

Note that dealing with note conflicts sucks in git right now, so always make sure to pull the latest notes before you start adding/pushing new ones.

If you made a commit and believe it is backport-worthy, then please add the note right-away and don't forget to push it!

We do not make use of notes namespaces so that all notes appear in normal "git log" outputs without any additional required options.

Stable Branch Repository

Stable branches are available from

Stable branches are started for certain releases of systemd and named after them, e.g. v208-stable. Stable branches are typically managed by distribution maintainers on an as needed basis. For example v208 has been chosen for stable as several distributions are shipping this version and the official/upstream cycle of v208-v209 was a long one due to kdbus work. If you are using a particular version and find yourself backporting several patches, you may consider pushing a stable branch here for that version so others can benefit. Please contact us if you are interested.

The following types of commits are cherry-picked onto those branches:

  • bugfixes (i.e. stuff marked for backports as described above)
  • documentation updates, when relevant to this version
  • hardware database additions, especially the keymap updates
  • small non-conflicting features deems safe to add in a stable release

Please try to ensure that anything backported to the stable repository is done with the git cherry-pick -x option such that text stating the original SHA1 is added into the commit message. This makes it easier to check where the code came from (as sometimes it is necessary to add small fixes as new code due to the upstream refactors that are deemed too invasive to backport as a stable patch.