59719f787e
This is mainly due to the lack of maintenance in nixpkgs. `google-chrome-{beta,dev}` depend on `chromium{Beta,Dev}`'s version info. `chromium{Beta,Dev}` are rarely updated and explicitly blocklisted by `hydra.nixos.org`, meaning they are almost always outdated and not cached in `cache.nixos.org`. `chromium{Beta,Dev}` were intended to fix the build derivation of each new major release (if something broke) *before* stable reached that new major release. Allowing for fast bumps in nixpkgs, especially if the stable bump contains very important critical security fixes. Something that can easily be replicated by using an early-stable release or by manually entering a dev/beta version string in stable's `upstream-info.nix`. This resolves exposing end-users to outdated and vulnerable `google-chrome-{beta,dev}` and `chromium{Beta,Dev}` versions. |
||
---|---|---|
.. | ||
doc/manual | ||
lib | ||
maintainers | ||
modules | ||
tests | ||
COPYING | ||
default.nix | ||
README.md | ||
release-combined.nix | ||
release-small.nix | ||
release.nix |
NixOS
NixOS is a Linux distribution based on the purely functional package management system Nix. More information can be found at https://nixos.org/nixos and in the manual in doc/manual.
Testing changes
You can add new module to your NixOS configuration file (usually it’s /etc/nixos/configuration.nix
). And do sudo nixos-rebuild test -I nixpkgs=<path to your local nixpkgs folder> --fast
.
Reviewing contributions
When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people’s installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.
Module updates
Module updates are submissions changing modules in some ways. These often contains changes to the options or introduce new options.
Reviewing process:
- Ensure that the module maintainers are notified.
- 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.
- Ensure that the introduced options are correct.
- Type should be appropriate (string related types differs in their merging capabilities,
loaOf
andstring
types are deprecated). - Description, default and example should be provided.
- Type should be appropriate (string related types differs in their merging capabilities,
- 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
- Ensure that changes that are not backward compatible are mentioned in release notes.
- Ensure that documentations affected by the change is updated.
Sample template for a module update review is provided below.
##### Reviewed points
- [ ] changes are backward compatible
- [ ] removed options are declared with `mkRemovedOptionModule`
- [ ] changes that are not backward compatible are documented in release notes
- [ ] module tests succeed on ARCHITECTURE
- [ ] options types are appropriate
- [ ] options description is set
- [ ] options example is provided
- [ ] documentation affected by the changes is updated
##### Possible improvements
##### Comments
New modules
New modules submissions introduce a new module to NixOS.
Reviewing process:
- 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
andstring
types are deprecated). - Description, default and example should be provided.
- Type should be appropriate (string related types differs in their merging capabilities,
- Ensure that module
meta
field is present- Maintainers should be declared in
meta.maintainers
. - Module documentation should be declared with
meta.doc
.
- Maintainers should be declared in
- Ensure that the module respect other modules functionality.
- For example, enabling a module should not open firewall ports by default.
Sample template for a new module review is provided below.
##### Reviewed points
- [ ] module path fits the guidelines
- [ ] module tests succeed on ARCHITECTURE
- [ ] options have appropriate types
- [ ] 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
##### Possible improvements
##### Comments