Policies

TL;DR

Condensed version of policies.

Only submit packages legally distributable, proprietary or not, but try not to PR things that are (a) already in Fedora, & (b) WIP / untested code. Get sources into most suitable folder in repo, 1 anda.hcl & spec file per folder. Otherwise PR whatever the heck you want.

Follow upstream version if stable; prefer %{unreleased_version}~%{commit_date}git.%{shortcommit} over %{latest_stable_version}^%{commit_date}git.%{shortcommit} otherwise. Suffix .nightly / -nightly in name for nightly tag. Upstream Git branches can be tag names.

Only 1 number is allowed in Release: 1%?dist / 1%{?dist}. Packager: Your name <mail@example.com> is REQUIRED.

If new package affects existing installs, MUST include in subrepos.

Ship GUI apps with appstream metadata and desktop file.

• Security policy: SECURITY.md file
• Code of conduct: CODE_OF_CONDUCT.md file
• Lifecycle policy: lifecycle page

End.

Submission Policy

• Use common sense.
• When it comes to submissions, anything is fair game, assuming that our policies are followed.
• You MUST have the rights or permission to redistribute the packaged software. Please check the license of the software. Besides that, there is no prohibition on proprietary licenses.
• Submissions must be maintained. We will reject submissions of unmaintained software. The only exception to this SHOULD be required dependencies of modern applications.
• Submissions MUST NOT be malicious.
• Submissions SHOULD include an auto-update script (update.rhai).
• Submissions SHOULD be placed in the corresponding directory in anda/, linked here.
  • Each folder MUST either contain folders and no source files (other files are exempted), or contain multiple files and no folders.
  • The following directories have a higher priority. Categorize your new package in the following order:
    1. fonts/
    2. system/ (bootloaders, kernels, drivers, ...)
    3. tools/buildsys/ (software used to build other software)
    4. devs/ (tools for software development)
    5. games/
    6. themes/
    7. docker/ (software related to containers)
    8. desktops/ (applications specific to a Desktop Environment)
    9. apps/ (GUI applications)
    10. langs/ (software written in/for a specific programming language)
    11. stardust/ (packages for the [Stardust XR[(https://stardustxr.org/) stack)
• When there are ambiguous or unspecified parts in our policies/guidelines, you SHOULD refer to Fedora's packaging guidelines.
• Low-quality contributions will be declined at the team's discretion.
• Do not include work-in-progress code or untested patches. See https://dont-ship.it/.

Maintenance Policy

• Anyone MAY make a PR (pull request) to an already existing package.
• Unmaintained packages may be removed at any time. Before doing so, we will create a GitHub issue to gauge community interest.
• Terra will only support the latest versions of Fedora, if a package doesn't build on the next version of Fedora, we might hold it back.

Technical Policies for Preamble

This section describes the guidelines for the preamble items, notably naming and versioning.

Tags

"tag" refers to different versions of the same software, as in their release schedule/model. For example, the zed package has 3 tags: stable, preview and nightly. (Some packages use tip instead of nightly.) Tags may be named after Git branches from upstream.

Having a different tag of the same software warrants a separate package, i.e., they MUST have separate spec files with separate Name:s. The tag SHOULD be specified in Name: using the format %{rawname}.%{tag} e.g. ghostty.tip, zed.preview, and kf6-kio.switcheroo.

Packages without any tags specified in Name: MUST be regarded as stable.

For UX reasons, some packages MAY consider specifying Provides: %{rawname}-%{tag}.

Versioning

Packages SHOULD follow one of the version formats below:

## (Release tag tracking (stable))
Version:  %{latest_stable_version}
## (Commit tacking (nightly off version tag))
Version:  %{latest_stable_version}^%{commit_date}git.%{shortcommit}
## (Commit tacking (no stable version tag))
Version:  %{unreleased_version}~%{commit_date}git.%{shortcommit}

git SHOULD be replaced with the correct VCS identifier for (b) and (c) as listed on the right.

If either commit tracking option is used, you MUST also include labels { nightly = 1 } in anda.hcl unless there is no update.rhai, as these two formats rely on the assumption that there is one %shortcommit for each %commit_date (and vice versa).

%unreleased_version refers to the expected version number for the next stable (or a more stable tag than nightly) release, while %latest_stable_version refers to the current latest released version number, preferably stable.

Commit tacking (nightly off version tag) SHOULD be used when there is a stable and nightly version of a package.

If upstream does not provide a version, use Commit tacking (no stable version tag) and replace %unreleased_version as 0.

Release Field

The Release: preamble MUST NOT contain information regarding upstream versioning, including but not limited to commit dates, commit hashes, software versions, tags, etc. Without approval from the team, packages MUST use the format Release: 1%?dist.

The release number SHOULD be incremented if changes are made to the package, unless the Version: changes.

Naming

Prefix/Suffix the packages in the following order

• Fonts MUST be suffixed with -fonts.
• Shared libraries SHOULD be suffixed with -libs.
  • Alternatively, the lib prefix is also allowed, but they SHOULD still provide -libs.
• Development libraries SHOULD be suffixed with -devel.
• If necessary, suffix -bash-completion (or other shells) and -doc.
• Postfix a tag if necessary (e.g. .nightly).

Packager Field

The package maintainer of a package MUST be added to the Packager: preamble as follows:

Packager: Raboneko <raboneko@fyralabs.com>

Subrepos

For f* branches, submissions that may introduce breaking changes MUST be included in our subrepos instead via the subrepo = "extras" label in anda.hcl. Valid subrepos include extras, nvidia, mesa, and multimedia (43 and later only).

For example, terra-mesa should be in extra as the dependency solver will resolve this package for matching "provides" (such as mesa-libEGL(x86-64)). libadwaita-nightly should be in extra since it provides pkgconfig(libadwaita-1), which is required by existing packages as a build dependency. yt-dlp-nightly can be included normally because it has no common provides with Fedora's yt-dlp.

AppStream MetaInfo & Desktop Files

All graphical applications that can be started by the user MUST provide a desktop entry and AppStream MetaInfo file. Other applications are also RECOMMENDED to do so.

Miscellaneous Terra Policies

Security Policy

Our security policy is documented in the SECURITY.md file.

Code of Conduct

Our code of conduct is documented in the CODE_OF_CONDUCT.md file.

Lifecycle Policy

Our support lifecycle is documented in the lifecycle page.