diff options
| author | Maximilian Bosch <maximilian@mbosch.me> | 2025-09-21 15:37:07 +0200 |
|---|---|---|
| committer | Maximilian Bosch <maximilian@mbosch.me> | 2025-10-05 22:59:25 +0200 |
| commit | 9f95c2ace2ba533a6d8072753b164d8d8ffc29b0 (patch) | |
| tree | b70946c463917bf18aed58a879cc49699821039c /CONTRIBUTING.md | |
| parent | webkitgtk_6_0: 2.48.6 → 2.50.0 (#444350) (diff) | |
| download | nixpkgs-9f95c2ace2ba533a6d8072753b164d8d8ffc29b0.tar.gz | |
linux: new workflow for kernel changes
See https://github.com/NixOS/nixpkgs/issues/437208#issuecomment-3288623669
Depends on https://github.com/NixOS/org/pull/172
As documented below, the idea is to essentially group all changes
rebuilding all VM tests with kernel updates and merge them together into
`master` whenever the Linux kernels get updated.
This documents the workflow of updates in the nixpkgs manual. While at
it, I removed the README from the packages because
* it's horribly outdated
* I didn't even know it exists which confirms that its discoverability
was very poor
and added the relevant portions into the nixpkgs manual as well.
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 38 |
1 files changed, 30 insertions, 8 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0508d2639de1..33f95e702871 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -430,20 +430,22 @@ gitGraph Here's an overview of the different branches: -| branch | `master` | `staging-next` | `staging` | -| --- | --- | --- | --- | -| Used for development | ✔️ | ❌ | ✔️ | -| Built by Hydra | ✔️ | ✔️ | ❌ | -| [Mass rebuilds][mass-rebuild] | ❌ | ⚠️ Only to fix Hydra builds | ✔️ | -| Critical security fixes | ✔️ for non-mass-rebuilds | ✔️ for mass-rebuilds | ❌ | -| Automatically merged into | `staging-next` | `staging` | - | -| Manually merged into | - | `master` | `staging-next` | +| branch | `master` | `staging-next` | `staging` | [`staging-nixos`](#test-driver-rebuild) | +| --- | --- | --- | --- | --- | +| Used for development | ✔️ | ❌ | ✔️ | ✔️ | +| Built by Hydra | ✔️ | ✔️ | ❌ | ❌ | +| [Mass rebuilds][mass-rebuild] | ❌ | ⚠️ Only to fix Hydra builds | ✔️ | ❌[^1] | +| Critical security fixes | ✔️ for non-mass-rebuilds | ✔️ for mass-rebuilds | ❌ | ✔️ | +| Automatically merged into | `staging-next` & `staging-nixos` | `staging` | - | - | +| Manually merged into | - | `master` | `staging-next` | `master` | The staging workflow is used for all stable branches with corresponding names: - `master`/`release-YY.MM` - `staging`/`staging-YY.MM` - `staging-next`/`staging-next-YY.MM` +[^1]: Except changes that cause no more rebuilds than kernel updates + # Conventions ## Branch conventions @@ -495,6 +497,26 @@ In order to help the decision, CI automatically assigns [`rebuild` labels](https As a rule of thumb, if the number of rebuilds is **500 or more**, consider targeting the `staging` branch instead of `master`; if the number is **1000 or more**, the pull request causes a mass rebuild, and should target the `staging` branch. See [previously merged pull requests to the staging branches](https://github.com/NixOS/nixpkgs/issues?q=base%3Astaging+-base%3Astaging-next+is%3Amerged) to get a sense for what changes are considered mass rebuilds. +Please note that changes to the Linux kernel are an exception to this rule. +These PRs go to `staging-nixos`, see [the next section for more context](#changes-rebuilding-all-tests). + +### Changes rebuilding all NixOS tests +[test-driver-rebuild]: #changes-rebuilding-all-tests + +Changes causing a rebuild of all NixOS tests get a special [`10.rebuild-nixos-tests`](https://github.com/NixOS/nixpkgs/issues?q=state%3Aopen%20label%3A10.rebuild-nixos-tests) label. +These changes pose a significant impact on the build infrastructure. + +Hence, these PRs should either target a `staging`-branch or `staging-nixos`, provided one of following conditions applies: + +* The label `10.rebuild-nixos-tests` is set, or +* The PR is a change affecting the Linux kernel. + +The branch gets merged whenever mainline kernel updates or critical security fixes land on the branch. +This usually happens on a weekly basis. + +Backports are not handled by such a branch. +The relevant PRs from this branch must be backported manually. + ## Commit conventions [commit-conventions]: #commit-conventions |