Skip to content

Latest commit

 

History

History
63 lines (45 loc) · 1.9 KB

CONTRIBUTING.md

File metadata and controls

63 lines (45 loc) · 1.9 KB
Raw

Contributing a Device Profile

1. Writing profiles

Create an appropriate directory and start writing your expression.

When setting an option, use lib.mkDefault unless:

  • The option must be set and the user should get an error if they try to override it.
  • The setting should merge with the user's settings (typical for list or set options).

For example:

{ lib }: {
  # Using mkDefault, because the user might want to disable tlp
  services.tlp.enable = lib.mkDefault true;
  # No need to use mkDefault, because the setting will merge with the user's setting
  boot.kernelModules = [ "tmp_smapi" ];
}

Where possible, use module imports to share code between similar hardware variants. In most cases, import:

  • a cpu module;
  • a gpu module;
  • either the pc or the laptop module;
  • either the HDD or the SSD module.

Try to avoid "opinionated" settings relating to optional features like sound, bluetooth, choice of bootloader etc. You can mention these in the readme.

Profiles should favor usability and stability, so performance improvements should either be conservative or be guarded behind additional NixOS module options. If it makes sense to have a performance-focussed config, it can be declared in a separate profile.

2. Adding Entry

Link the profile in the table in README.md and in flake.nix.

3. Testing

Run ./tests/run.py to test building. The test script script will parse all the profiles from the README.md.

You can also just specify a single profile like this:

 ./tests/run.py '<nixos-hardware/purism/librem/15v3>'

Because profiles can only be tested with the appropriate hardware, quality assurance is up to you.

For reviewers:

This repository has bors enabled for easier merging after a successfull build: