📋 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

🪞 Mirrors of original Linux repositories

The server 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

🏷️ 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

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

%%{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

%%{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

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:

ℹ️ 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

%%{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

%%{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

ℹ️ 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.

5.2 🧪 LANDAU Linux RC stage

ℹ️ 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

5.4 🔄 Maintenance of stable and LTS versions

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:

📌 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

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

🏗️ 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.

---
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

🔄 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

⬅️ Back to LANDAU Linux page