diff options
99 files changed, 1068 insertions, 605 deletions
diff --git a/.github/workflows/backport.yml b/.github/workflows/backport.yml index 2e9e20331bf6..9343e29d5963 100644 --- a/.github/workflows/backport.yml +++ b/.github/workflows/backport.yml @@ -24,7 +24,7 @@ jobs: with: ref: ${{ github.event.pull_request.head.sha }} - name: Create backport PRs - uses: korthout/backport-action@v2.1.0 + uses: korthout/backport-action@v2.1.1 with: # Config README: https://github.com/korthout/backport-action#backport-action copy_labels_pattern: 'severity:\ssecurity' diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index dadda215b0df..f204758e7be8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -465,7 +465,7 @@ Is the change [acceptable for releases][release-acceptable] and do you wish to h - No: Use the `master` branch, do not backport the pull request. - Yes: Can the change be implemented the same way on the `master` and release branches? For example, a packages major version might differ between the `master` and release branches, such that separate security patches are required. - - Yes: Use the `master` branch and [backport the pull request](#backporting-changes). + - Yes: Use the `master` branch and [backport the pull request](#how-to-backport-pull-requests). - No: Create separate pull requests to the `master` and `release-XX.YY` branches. Furthermore, if the change causes a [mass rebuild][mass-rebuild], use the appropriate staging branch instead: diff --git a/doc/languages-frameworks/javascript.section.md b/doc/languages-frameworks/javascript.section.md index 79cb09572503..0bb9959a5105 100644 --- a/doc/languages-frameworks/javascript.section.md +++ b/doc/languages-frameworks/javascript.section.md @@ -13,7 +13,7 @@ If you find you are lacking inspiration for packing javascript applications, the ### Github {#javascript-finding-examples-github} - Searching Nix files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+language%3ANix&type=code> -- Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+filename%3Aflake.nix&type=code> +- Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+path%3A**%2Fflake.nix&type=code> ### Gitlab {#javascript-finding-examples-gitlab} diff --git a/maintainers/maintainer-list.nix b/maintainers/maintainer-list.nix index 4aa8608da7aa..85ff0ec04f4e 100644 --- a/maintainers/maintainer-list.nix +++ b/maintainers/maintainer-list.nix @@ -3692,6 +3692,12 @@ githubId = 1222362; name = "MatÃas Lang"; }; + criyle = { + email = "i+nixos@goj.ac"; + name = "Yang Gao"; + githubId = 6821729; + github = "criyle"; + }; CRTified = { email = "carl.schneider+nixos@rub.de"; matrix = "@schnecfk:ruhr-uni-bochum.de"; diff --git a/nixos/README.md b/nixos/README.md index b3cd9d234fa6..d0257e12d933 100644 --- a/nixos/README.md +++ b/nixos/README.md @@ -21,12 +21,14 @@ Reviewing process: - Ensure that the module maintainers are notified. - [CODEOWNERS](https://help.github.com/articles/about-codeowners/) will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers. - Ensure that the module tests, if any, are succeeding. + - You may invoke OfBorg with `@ofborg test <module>` to build `nixosTests.<module>` - Ensure that the introduced options are correct. - Type should be appropriate (string related types differs in their merging capabilities, `loaOf` and `string` types are deprecated). - Description, default and example should be provided. - Ensure that option changes are backward compatible. - - `mkRenamedOptionModuleWith` provides a way to make option changes backward compatible. -- Ensure that removed options are declared with `mkRemovedOptionModule` + - `mkRenamedOptionModuleWith` provides a way to make renamed option backward compatible. + - Use `lib.versionAtLeast config.system.stateVersion "23.11"` on backward incompatible changes which may corrupt, change or update the state stored on existing setups. +- Ensure that removed options are declared with `mkRemovedOptionModule`. - Ensure that changes that are not backward compatible are mentioned in release notes. - Ensure that documentations affected by the change is updated. @@ -55,6 +57,7 @@ New modules submissions introduce a new module to NixOS. Reviewing process: +- Ensure that all file paths [fit the guidelines](../CONTRIBUTING.md#file-naming-and-organisation). - Ensure that the module tests, if any, are succeeding. - Ensure that the introduced options are correct. - Type should be appropriate (string related types differs in their merging capabilities, `loaOf` and `string` types are deprecated). @@ -76,9 +79,9 @@ Sample template for a new module review is provided below. - [ ] options have default - [ ] options have example - [ ] options have descriptions -- [ ] No unneeded package is added to environment.systemPackages -- [ ] meta.maintainers is set -- [ ] module documentation is declared in meta.doc +- [ ] No unneeded package is added to `environment.systemPackages` +- [ ] `meta.maintainers` is set +- [ ] module documentation is declared in `meta.doc` ##### Possible improvements |