landau-linux: en: Translate landau-linux/maintenance

Translate landau-linux/maintenance page into English.

Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>

1 files changed, 538 insertions, 0 deletions

diff --git a/content/en/landau-linux/maintenance/_index.md b/content/en/landau-linux/maintenance/_index.md
new file mode 100644
index 0000000..248d00e
--- /dev/null
+++ b/content/en/landau-linux/maintenance/_index.md
@@ -0,0 +1,538 @@
+---
+title: "📋 LANDAU Linux Kernel Maintenance Manifest"
+description: "Description of the LANDAU Linux kernel development process — branches, releases, versioning, and maintenance"
+draft: false
+---
+
+# 📋 LANDAU Linux Kernel Maintenance Manifest
+
+> **LANDAU Linux** is a fork of the Linux kernel with its own versioning scheme and a predictable release cycle. This document describes the formal maintenance process of the project.
+
+---
+
+## 🧭 1. Overview
+
+### 🎯 Purpose
+
+To provide a stable, predictable, and documented release process for LANDAU Linux with tracking of the original Linux kernel repository.
+
+### 📖 Glossary
+
+| Term | Full name | Description |
+| ---- | --------- | ----------- |
+| **V** | VERSION | Major version of the Linux kernel. Defines the main version number (e.g., `6` in `6.12.7`). |
+| **P** | PATCHLEVEL | Middle version of the Linux kernel. Defines the minor version number (e.g., `12` in `6.12.7`). |
+| **S** | SUBLEVEL | Minor version of the Linux kernel. Defines the stable update number (e.g., `7` in `6.12.7`). |
+| **E** | EXTRAVERSION | A field in the Linux kernel version into which the LANDAU Linux version is embedded. The Linux kernel usually uses it for `-rc` releases. |
+| **MR** | Merge Request | A request to merge one Git branch into another. It is submitted as a link to a Git repository and a branch of an authorised maintainer with a formal description. |
+| **RMW** | Rebase & Merge Window | A time period (2 weeks) during which LANDAU maintainers rebase their changes onto a new base kernel version. |
+| **Bundle** | — | The full set of changes in the LANDAU Linux repository that distinguish it from the original Linux kernel. There is a global Bundle and per‑maintainer Bundles. |
+| **EOL** | End-of-Life | The end of support for a released product version. The branch no longer receives updates and is archived. |
+
+### 🪞 Mirrors of original Linux repositories
+
+The server **[git.rulkc.org](https://git.rulkc.org)** hosts continuously updated mirrors of:
+
+- 🔷 `torvalds/linux` — main Linux kernel tree
+- 🔷 `stable/linux` — stable Linux kernel releases
+- 🔷 `linux-next` — integration tree linux‑next
+
+---
+
+## 🏷️ 2. Versioning scheme
+
+### 📐 LANDAU Linux version format
+
+```
+VERSION.PATCHLEVEL.SUBLEVEL.lXYZ
+```
+
+| Component | Example | Description |
+|-----------|--------|----------|
+| `VERSION` | `7` | Kernel major version |
+| `PATCHLEVEL` | `0` | Kernel minor version |
+| `SUBLEVEL` | `12` | Kernel stable update number |
+| `l-rcX` | `l-rc1`, `l-rc2` | Build number of a LANDAU Linux release candidate |
+| `lXYZ` | `l`, `l1` | Build number of a stable LANDAU Linux release |
+
+### 🏷️ Git tags
+
+Annotated tags are used in the format:
+
+```
+v7.0.l-rcX
+v7.0.lXYZ
+```
+
+Example: `v7.0.l-rc1`, `v7.0.l`, `v7.0.l5`
+
+---
+
+## 🌿 3. Git branch strategy
+
+### 📌 Main Git branches
+
+| Branch | Purpose |
+| ------ | ------- |
+| `landau-next` | Git branch for the next LANDAU Linux release, where maintainers submit their MRs |
+| `landau-V.P.y` | Current Git branch for a LANDAU Linux release based on the stable Linux kernel version V.P |
+
+> `landau-next` is the Git branch where all maintainers work together. Conflicts are resolved here, and all MRs are collected to create the `landau-V.P.y` branch. At the start of a new RMW, its HEAD is forcibly moved (_force‑push_) to the new Linux kernel release.
+
+### ⏳ Lifecycle of Git branches
+
+```mermaid
+%%{init: {
+  'theme': 'base',
+  'themeVariables': {
+    'background': '#002b36',
+    'primaryColor': '#073642',
+    'primaryTextColor': '#839496',
+    'primaryBorderColor': '#586e75',
+    'lineColor': '#b58900',
+    'secondaryColor': '#002b36',
+    'tertiaryColor': '#073642',
+    'edgeLabelBackground': '#002b36',
+    'nodeBorder': '#586e75',
+    'nodeTextColor': '#93a1a1',
+    'clusterBkg': '#002b36',
+    'clusterBorder': '#586e75',
+    'fontSize': '20px',
+    'fontFamily': 'monospace'
+  },
+  'flowchart': {
+    'nodeSpacing': 80,
+    'rankSpacing': 30,
+    'curve': 'basis',
+    'padding': 10
+  }
+}}%%
+flowchart TB
+    subgraph Block1["Release preparation (RC stage)"]
+        direction LR
+        A["<b>landau-next</b> → <b>linux-V.P.y</b>"]
+        B["Stabilize <b>landau-next</b>"]
+        C{"Is <b>landau-next</b><br>code stable?"}
+        D(("•••"))
+        E["P = P + 1"]
+
+        A --> B
+        B --> C
+        C -->|No| B
+        C -->|Yes| D
+        C -->|Yes| E
+        E -.->|Wait for release P| A
+    end
+```
+
+```mermaid
+%%{init: {
+  'theme': 'base',
+  'themeVariables': {
+    'background': '#002b36',
+    'primaryColor': '#073642',
+    'primaryTextColor': '#839496',
+    'primaryBorderColor': '#586e75',
+    'lineColor': '#b58900',
+    'secondaryColor': '#002b36',
+    'tertiaryColor': '#073642',
+    'edgeLabelBackground': '#002b36',
+    'nodeBorder': '#586e75',
+    'nodeTextColor': '#93a1a1',
+    'clusterBkg': '#002b36',
+    'clusterBorder': '#586e75',
+    'fontSize': '20px',
+    'fontFamily': 'monospace'
+  },
+  'flowchart': {
+    'nodeSpacing': 80,
+    'rankSpacing': 30,
+    'curve': 'basis',
+    'padding': 10
+  }
+}}%%
+flowchart TB
+    subgraph Block2["LANDAU Linux release"]
+        direction LR
+        A(("•••"))
+        B["<b>landau-V.P.y</b> → <b>landau-next</b>"]
+        C["Maintain <b>landau-V.P.y</b>"]
+        D{"Is <b>linux-V.P.y</b><br><b>EOL</b>?"}
+        E["Archive <b>landau-V.P.y</b>"]
+
+        A --> B
+        B --> C
+        C --> D
+        D -->|No| C
+        D -->|Yes| E
+    end
+```
+
+| Stage | Action |
+| ----- | ------ |
+| 🛑 Start | Force‑push `landau-next` to the base Linux kernel version    |
+| 🔧 Development | Collect and stabilize LANDAU changes in the `landau-next` branch |
+| 🆕 Release | Create `landau-V.P.y` from the stable `landau-next` |
+| 🔧 Maintenance | Collect bug fixes in the `landau-V.P.y` branch |
+| 🐢 End of support | The upstream version reaches EOL |
+
+> In the basic model, _maintenance_ means periodic synchronisation of `landau-V.P.y` with the upstream `linux-V.P.y` branch.
+
+---
+
+## 📅 4. Release schedule
+
+### ⏱️ Linux kernel release cycle
+
+The original Linux kernel repository follows this development cycle:
+
+| Phase | ⏰ Duration | 📝 Description |
+| ----- | ----------- | -------------- |
+| Development | 9‑10 weeks | Preparation for the new release |
+| Rebase & Merge Window | 2 weeks | Accept new Merge Requests from maintainers |
+| RC testing | 7‑8 weeks  | Test release candidates |
+| Final release | — | Publish the stable kernel |
+
+> ℹ️ **Important**: Since LANDAU Linux releases are based on stable Linux kernel releases, the current development cycle always lags behind the latest Linux kernel version by **1 PATCHLEVEL**.
+
+---
+
+## 🔄 5. LANDAU Linux release process
+
+### 📊 Release full cycle
+
+```mermaid
+%%{init: {
+  'theme': 'base',
+  'themeVariables': {
+    'background': '#002b36',
+    'primaryColor': '#073642',
+    'primaryTextColor': '#839496',
+    'primaryBorderColor': '#586e75',
+    'lineColor': '#b58900',
+    'secondaryColor': '#002b36',
+    'tertiaryColor': '#073642',
+    'edgeLabelBackground': '#002b36',
+    'nodeBorder': '#586e75',
+    'nodeTextColor': '#93a1a1',
+    'fontSize': '20px',
+    'fontFamily': 'monospace'
+  },
+  'flowchart': {
+    'nodeSpacing': 80,
+    'rankSpacing': 30,
+    'curve': 'basis',
+    'padding': 10
+  }
+}}%%
+flowchart TB
+    subgraph Block1["Release preparation (RC stage)"]
+        direction LR
+        A["📦 New Linux kernel release"] --> B
+        B(["🔓 1. LANDAU Linux RMW<br>(~2 weeks)"]) --> C
+        C["🔧 Merge and integrate Bundles"] --> D
+        D(["🔓 2. LANDAU Linux RC<br>(~1 week per RC)"]) --> E
+        E["🔧 Fix bugs<br>(release RC)"] --> F
+        F(("•••"))
+    end
+```
+
+```mermaid
+%%{init: {
+  'theme': 'base',
+  'themeVariables': {
+    'background': '#002b36',
+    'primaryColor': '#073642',
+    'primaryTextColor': '#839496',
+    'primaryBorderColor': '#586e75',
+    'lineColor': '#b58900',
+    'secondaryColor': '#002b36',
+    'tertiaryColor': '#073642',
+    'edgeLabelBackground': '#002b36',
+    'nodeBorder': '#586e75',
+    'nodeTextColor': '#93a1a1',
+    'fontSize': '20px',
+    'fontFamily': 'monospace'
+  },
+  'flowchart': {
+    'nodeSpacing': 80,
+    'rankSpacing': 30,
+    'curve': 'basis',
+    'padding': 10
+  }
+}}%%
+flowchart TB
+    subgraph Block2["LANDAU Linux release"]
+        direction LR
+        A(("•••")) --> B
+        B(["✅ 3. LANDAU Linux release"]) --> C
+        C["🔧 Publish LANDAU Linux<br>changes"] --> D
+        D(["🔓 4. LANDAU Linux maintenance"]) --> E
+        E["🔧 Fix bugs and<br>sync SUBLEVEL"] --> F
+        F(["🐢 5. LANDAU Linux EOL"])
+    end
+```
+
+### 5.1 🆕 RMW stage of LANDAU Linux
+
+| Step | Action                                                       |
+| ---- | ------------------------------------------------------------ |
+| 1    | Create the `landau-next` branch from the first stable Linux kernel release |
+| 2    | Announce the collection of LANDAU Linux changes from downstream maintainers |
+| 3    | Apply LANDAU Linux changes to `landau-next`                  |
+| 4    | Request resubmission of changes in case of complex conflicts |
+| 5    | Perform basic build testing of the resulting `landau-next` branch |
+| 6    | Update `EXTRAVERSION` to `l-rc1` and create a commit "LANDAU Linux V.P.l-rc1" |
+| 7    | Tag the commit with an annotated tag `vV.P.l-rc1`            |
+
+> ℹ️ The `EXTRAVERSION` variable in stable Linux kernel releases is left empty, so it can be used to store LANDAU Linux versions. The original `VERSION`, `PATCHLEVEL`, `SUBLEVEL` values are kept to indicate the upstream kernel version.
+
+| Parameter | Value |
+| --------- | ----- |
+| ⏱️ Duration  | **~about 2 weeks** |
+| 🎯 Focus     | Collection and basic sanity testing of products |
+| 🏷️ Releases  | l‑rc1 |
+| 🔧 Fixes     | Minor issues are resolved in merge commits. Major ones require a resubmission from the maintainer. |
+
+### 5.2 🧪 LANDAU Linux RC stage
+
+| Step | Action |
+| ---- | ------ |
+| 1 | Receive corrective LANDAU Linux changes from downstream maintainers |
+| 2 | Apply corrective changes to `landau-next` |
+| 3 | Perform basic build testing of the resulting `landau-next` branch |
+| 4 | Create a commit "LANDAU Linux V.P.l‑rcX" with the incremented `EXTRAVERSION` RC number |
+| 5 | Tag the commit with an annotated tag `vV.P.l‑rcX` |
+| 6 | Go to step 1 if errors are found |
+
+| Parameter | Value |
+| --------- | ----- |
+| ⏱️ Duration | about 1 week per RC, but no more than 7‑8 weeks total |
+| 🎯 Focus | Regression testing, stability, feature validation |
+| 🏷️ Releases | l‑rc1, l‑rc2, l‑rc3, ... |
+| 🔧 Fixes | Applied directly to the release branch on request from downstream maintainers |
+
+> ℹ️ Stabilization of the `landau-next` branch (no critical bugs found in the current RC cycle) signals the end of the RC stage and the move to the final release.
+
+### 5.3 ✅ Final release
+
+| Step | Action |
+| ---- | ------ |
+| 1 | Ensure no major issues remain in the last RC phase |
+| 2 | Update `EXTRAVERSION` to `l` and create a commit "LANDAU Linux V.P.l" |
+| 3 | Tag the commit with an annotated tag `vV.P.l` |
+| 4 | Create the `landau-V.P.y` branch based on the last LANDAU Linux RC release |
+
+| Parameter | Value |
+| --------- | ----- |
+| ⏱️ Duration | more than 1 week in the last RC phase |
+| 🎯 Focus | Stabilization of collected changes and publication of the changelog |
+| 🏷️ Releases | l |
+| 🔧 Fixes | None during the last RC phase |
+
+### 5.4 🔄 Maintenance of stable and LTS versions
+
+| Step | Action | Example |
+| ---- | ------ | ------- |
+| 1 | Determine the latest `SUBLEVEL` in the upstream stable Linux kernel branch | `v7.0.1` |
+| 2 | Merge changes from the upstream stable kernel branch into `landau-V.P.y` | `git merge v7.0.1` |
+| 3 | Receive corrective LANDAU Linux changes from downstream maintainers | - |
+| 4 | Apply corrective LANDAU changes to `landau-V.P.y` if any | - |
+| 5 | Increment `EXTRAVERSION` by one and create a commit "LANDAU Linux V.P.Y.lX" | `l` → `l1` |
+| 6 | Tag the commit with an annotated tag `vV.P.Y.lX` | `v7.0.1.l1` |
+
+| Parameter | Value |
+| --------- | ----- |
+| ⏱️ Duration | Until the upstream kernel version reaches EOL |
+| 🎯 Focus | Fixing critical bugs found in the stable LANDAU Linux release |
+| 🏷️ Releases | `l1`, `l2`, `l3`, ... |
+| 🔧 Fixes | Applied on request from downstream maintainers as corrective releases |
+
+LANDAU Linux maintainers have decided to **natively support stable and LTS versions** of the Linux kernel until they reach EOL. However, corrective LANDAU Linux changes are guaranteed to be backported only to the LANDAU Linux based on the latest LTS kernel version. Backporting to older versions is possible if resources permit.
+
+⚠️ Integration rules for stable and LTS LANDAU Linux branches:
+
+| ✅ Allowed          | ❌ Not allowed           |
+| ------------------- | ------------------------ |
+| Security fixes      | Backport of new features |
+| Critical bug fixes  | New drivers              |
+| Stabilizing patches | Subsystem changes        |
+| Documentation       | Any non‑bugfix changes   |
+
+> 📌 **Principle**: Only the changelog that existed at the time the upstream LTS branch was created is maintained.
+
+### 5.5 🔄 End of Life (EOL) for LANDAU Linux Release
+
+| Step | Action |
+| ---- | ------ |
+| 1 | Receive EOL status for the upstream stable kernel version |
+| 2 | Announce the end of support for LANDAU Linux in the `landau-V.P.y` branch |
+
+| Parameter | Value |
+| --------- | ----- |
+| ⏱️ Duration | At least several corrective releases of the stable LANDAU Linux version before EOL is declared |
+| 🎯 Focus | Termination of release support |
+| 🏷️ Releases | lZ (last build) |
+| 🔧 Fixes | Not applied |
+
+Support for stable and LTS versions of LANDAU Linux ends either when the upstream kernel version reaches EOL, or after the release of a LANDAU Linux based on the latest LTS kernel version (whichever comes first).
+
+---
+
+## 6. 👤 Maintainer responsibilities
+
+| Area | Responsibility |
+| ---- | -------------- |
+| 👁️ Monitoring upstream repository | Track new releases and RC cycles |
+| 📦 Applying patches | Integrate LANDAU‑specific kernel changes |
+| 🏷️ Tag management | Create annotated tags in the format vV.P.lZ |
+| 🧪 RC coordination | Organise testing of release candidates |
+| 🔒 Security | Monitor and apply security fixes |
+| 📝 Documentation | Maintain the changelog for each LANDAU release |
+
+### 🏗️ Maintainer personal repositories
+
+Maintainers store and develop their own forks of the Linux kernel in their personal repositories, containing the set of changes they are responsible for.
+
+Maintainers are free to choose how to organise their personal repositories. For example, they may split independent changes into separate Git branches by subsystem and send individual MRs for each, or merge them into a single Git branch and send one holistic MR. However, they must follow the rule of **continuity of previous changes and minimisation of merge conflicts**. That is, the Git branch submitted in an MR to the lead maintainer must preserve the history of previous LANDAU Linux changes and their fixes, and must also contain the latest version of the upstream kernel for which the LANDAU Linux release is being prepared.
+
+To meet this requirement, the **double‑merge** approach is recommended: first, the maintainers of their own LANDAU Linux repositories (sub‑LANDAU Linux) merge their Git branches with `landau-next`, resolve all conflicts, and only then send MRs during the RMW stage.
+
+```mermaid
+---
+config:
+    gitGraph:
+        parallelCommits: false
+        mainBranchName: 'linux-V.P.y'
+---
+gitGraph
+    branch baikal-next order: 2
+    branch amlogic-next order: 3
+    commit
+    commit
+    checkout baikal-next
+    commit
+    commit
+    checkout linux-V.P.y
+    commit
+    commit
+    commit id: "Linux V.P" tag: "vV.P"
+    branch landau-next order: 1
+    commit id: " " type: HIGHLIGHT
+    checkout amlogic-next
+    merge landau-next
+    checkout baikal-next
+    merge landau-next
+    checkout landau-next
+    merge amlogic-next
+    merge baikal-next
+    commit id: "LANDAU Linux V.P.l-rc1" tag: "vV.P.l-rc1"
+```
+
+This way, the main burden of conflict resolution falls on the downstream maintainers. The lead maintainer only needs to collect all MRs into `landau-next`. If even then complex conflicts arise, the lead maintainer may ask for a repeat double‑merge cycle so that cross‑sub‑LANDAU conflicts are resolved on the downstream side.
+
+Optionally, maintainers may maintain Git branches with patch sets for later submission to the upstream Linux kernel. Until integration, those patch sets may "absorb" fixes and stylistic changes during rebasing onto a new kernel version. This simplifies maintenance of such Git branches by minimising the change log, which would otherwise be unnecessary when merging into the upstream kernel.
+
+---
+
+## 📖 7. Example of a full release cycle
+
+### Initial data
+
+Linux kernel version **`7.0`** has been released. This means that in the upstream Linux repository, changes added during the merge window have stabilized, the RC phase is finished, `EXTRAVERSION` is empty, the last commit marks the Linux 7.0 release, and a new branch `linux-7.0.y` appears in the stable/LTS Git repository.
+
+### 📍 Step‑by‑step example
+
+#### 👁️ Scheme
+
+| Stage | Action | Result | Build version |
+| ----- | ------ | ------ | ------------- |
+| 1 | Force‑push `landau-next` to `v7.0` | `landau-next` | — |
+| 2 | Start RMW | `landau-next` | N/A |
+| 3 | Create RC1 | `v7.0.l‑rc1` | `7.0.l‑rc1` |
+| 4 | Create RC2 | `v7.0.l‑rc2` | `7.0.l‑rc2` |
+| 5 | Create RC3 | `v7.0.l‑rc3` | `7.0.l‑rc3` |
+| 6 | Final release and create numbered Git branch | v7.0.l and `landau-7.0.y`         | 7.0.l         |
+| 7 | Upstream release 7.0.1 appears               | Merge changes into `landau-7.0.y` | —             |
+| 8 | Bump version                                 | v7.0.1.l1                         | 7.0.1.l1      |
+| 9 | Upstream 7.0.x reaches EOL                   | `landau-7.0.y` is archived        | —             |
+
+#### 🔄 Detailed process:
+
+1. **New stable Linux kernel release** (e.g., v7.0 after 7 weeks of stabilization)
+2. **Open LANDAU Linux RMW** — we take 2 weeks for our LANDAU Linux release:
+   - Merge patch series (MRs) into `landau-next`, based on v7.0
+   - Resolve all conflicts there
+   - Build initial common kernel images
+3. **Release RC versions** (e.g., v7.0.l‑rc1) — RC releases are made from the `landau-next` branch
+4. **Testing** — lasts up to 7 weeks (may be shorter):
+   - Release RC versions: l‑rc1, l‑rc2, l‑rc3, etc.
+5. **Final release and stable branch creation**:
+   - Release v7.0.l
+   - Create stable Git branch **`landau-7.0.y`** from the last release
+   - All further maintenance of this version is done in `landau-7.0.y`
+6. **End of the `landau-next` cycle**:
+   - The `landau-next` branch stops growing after the first v7.0.l release
+   - It switches back to step 1 when a new stable release (e.g., v7.1) appears upstream
+7. **Integrate new SUBLEVEL changes from upstream stable kernel**:
+   - If upstream changes SUBLEVEL (e.g., 7.0.1), we merge that release into **`landau-7.0.y`**
+   - Bump our version: v7.0.1.l1
+   - That is, the LANDAU Linux version increases, and SUBLEVEL gets the new value according to the integrated changes
+8. **Stable version evolution**:
+   - The stable LANDAU Linux v7.0 is maintained in the `landau-7.0.y` branch
+9. **End of release support**:
+   - Support for the LANDAU Linux branch ends when the upstream kernel version no longer has stable status on kernel.org (e.g., 7.0 reaches EOL)
+10. **LTS support**:
+    - If the upstream kernel goes LTS, LANDAU supports it until its EOL
+    - Only LANDAU Linux fixes (no new features) and new SUBLEVEL updates are brought in
+11. **Support guarantees**:
+    - LANDAU Linux Owners guarantee support for **the latest LTS kernel at any time**
+    - Support for older LTS kernels is considered if resources allow
+
+#### 🏷️ Full tag chain example
+
+ For Linux kernel 7.0.x:
+
+v7.0.l‑rc1 → v7.0.l‑rc2 → v7.0.l‑rc3 → v7.0.l → (branch `landau-7.0.y` created) → v7.0.1.l1 → v7.0.2.l2 → ...
+
+```
+v7.0.l-rc1  →  v7.0.l-rc2  →  v7.0.l-rc3  →  v7.0.l
+                                                  ↓
+                                      branch landau-7.0.y created
+                                                  ↓
+                                          v7.0.1.l1  →  v7.0.2.l2  →  ...
+```
+
+---
+
+### Patch requirements
+
+TODO
+
+### Pull requests
+
+TODO
+
+### Maintainers B4 usage
+
+TODO
+
+---
+
+## 📚 8. Links and resources
+
+| Resource                    | URL                                  |
+| --------------------------- | ------------------------------------ |
+| 📦 LANDAU Linux repositories   | https://git.rulkc.org/pub/scm/landau |
+| 🪞 Linux repository mirrors    | https://git.rulkc.org                |
+| 🔗 Upstream Linux repositories | https://kernel.org                   |
+
+---
+
+<div style="display: flex; justify-content: space-between; align-items: center; padding: 1rem 0; margin-top: 2rem; border-top: 1px solid #30363d; font-size: 14px; flex-wrap: wrap; gap: 10px;">
+  <span>📌 <strong>Current version:</strong> 1.0</span>
+  <span>✍️ <strong>Maintained by:</strong> LANDAU Maintainers</span>
+  <span>📅 <strong>Updated:</strong> 2026-07</span>
+</div>
+
+[⬅️ Back to LANDAU Linux page](../)