Introduction
The Terra RFC Book is a collection of casual documentation for Terra.
Anyone can submit pull requests / RFCs to this repository. You can write about current problems, suggestions, tutorials, examples, etc. Anything Terra-related can go here.
The RFC site is available here: https://terrapkg.github.io/rfcs/
Terra RFCs
This describes Terra RFCs.
Why This Needs to Exist
We need more ideas on how Terra can become a better repository for everyone. By introducing an RFC repository, we encourage anyone interested to provide their opinions.
The Terra Community
Terra is possible thanks to support from many different people, including our upstream distributions and upstream software projects. To further improve our transparency and communications, having a public repository of e.g. what we might do is probably a good idea.
Questions?
You can create “replies” by creating pull requersts and create new files in the corresponding folder.
For example, to reply to this RFC, create src/0000-rfcs/0000-reply-title.md.
0000-test
test
How Terra Components are/were Named
—mado
Andaman
anda is our build toolchain for building rpm packages. It’s currently just a thin wrapper around rpmbuild and mock.
Andaman is named after the Andaman Sea by Cappy. (Fedora → Sea reference; Ultramarine Linux Thai origin → Andaman)
Subatomic
Pretty sure subatomic was named by Cappy. It also could be Lea. I’m not too sure.
Jade mentioned that subatomic was named that way to fit into other tauOS components. For context, “common” in Andaman Common repositories was referring to Ultramarine and tauOS.
Kiritan
Obviously I was the one who named it きりたん. The motivation is described by that manga you see in README and the blog post.
Tetsudou
Me and Cappy named tetsudou after なんとか 鉄道の夕 by 海茶. Cappy was looking for a J-pop song, I was looking for a Kaiwai song. And yes, we had (or have?) a tradition of naming things after Japanese music.
Madoguchi
Madoguchi was named by me mado after JR みどりの窓口. There was no particular reason other than… well, you see, an API kinda acts like a service desk or honestly I don’t know.
Tuatara
Quote from internal conversations:
a lizard like reptile that lives along rocks so…terra relations also sounds like Terra
gawr gura
…
0002-reserved
reserved by mado
Terra Commit Messages
— mado
Rationale
I would like to submit a new commit message format for packaging in Terra. We are currently using [conventional commits] but it is not really designed for the needs of Terra. It’s a solution for say coding projects that didn’t have any kind of commit formats. It works, because well having 1 format is better than having none at all, but it’s definitely not the best, especially since we are dealing with package sources, and a lot of package sources every single day.
Scope
I believe the format should be used only when submitting changes that modify package sources. For example, changes to documentations and workflow files should not use this format.
Format
The (first line of the) commit message should start with the short package name, which is the
package name used on the name of the .spec file. For example, the short package name for
anki-bin.spec is anki-bin.
The name shall then be followed by : (colon and 1 space) and a short, concise description of the
commit. Then, optionally add a new line and then provide additional context (similar to
[conventional commits]).
For new package additions, the parts after the short package name can be omitted entirely.
I recommend having the first line of the additioanl context to be something like Fix #1234 or
Close #1234.
Special Cases
- when removing packages, just write
-anki-bin(prefix package name with-) - I figured some people might think it’s a bit weird that writing only
zed-nightlyalready means adding the package, so having a+prefix is also allowed.
Examples
When adding a new package:
zed-nightly
+nim
When fixing a package:
fresh: bdep pkgconfig(icu-uc)
When adding features(?) to a package:
ghostty-tip: track each tip release
When removing a package:
-zig0.15