JakeHillion/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #8738 from devhell/contributing

Browse Source 
CONTRIBUTING.md: Some minor clean-ups
This commit is contained in:
Pascal Wittmann 2015-07-10 22:59:00 +02:00
commit 6ad8fab785
1 changed files with 8 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
CONTRIBUTING.md
View File

@ -20,7 +20,7 @@
git checkout -b 'fix/pkg-name-update'
```
* Please avoid working directly on the `master` branch.
* Make commits of logical units.
* Make commits of logical units.
* If you removed pkgs, made some major NixOS changes etc., write about them in `nixos/doc/manual/release-notes/rl-unstable.xml`.
* Check for unnecessary whitespace with `git diff --check` before committing.
* Format the commit in a following way:
@ -37,12 +37,12 @@
* `nginx service: refactor config generation`
* Test your changes. If you work with
* nixpkgs:
* update pkg ->
* update pkg ->
* `nix-env -i pkg-name -f <path to your local nixpkgs folder>`
* add pkg ->
* add pkg ->
* Make sure it's in `pkgs/top-level/all-packages.nix`
* `nix-env -i pkg-name -f <path to your local nixpkgs folder>`
* _If you don't want to install pkg in you profile_.
* _If you don't want to install pkg in you profile_.
* `nix-build -A pkg-attribute-name <path to your local nixpkgs folder>/default.nix` and check results in the folder `result`. It will appear in the same directory where you did `nix-build`.
* If you did `nix-env -i pkg-name` you can do `nix-env -e pkg-name` to uninstall it from your system.
* NixOS and its modules:
@ -70,10 +70,9 @@
## Commit policy
* Commits must be sufficiently tested before being merged, both the master and staging branches.
* Hydra builds for master and stagingshould not be used as testing platform, it's a build farm for changes that have been already tested.
* Commits must be sufficiently tested before being merged, both for the master and staging branches.
* Hydra builds for master and staging should not be used as testing platform, it's a build farm for changes that have been already tested.
* Master should only see non-breaking commits that do not cause mass rebuilds.
* Staging should only see non-breaking mass-rebuild commits. That means it's not to be used for testing, changes must have been well tested already. [Read policy here](http://comments.gmane.org/gmane.linux.distributions.nixos/13447).
* Staging should only see non-breaking mass-rebuild commits. That means it's not to be used for testing, and changes must have been well tested already. [Read policy here](http://comments.gmane.org/gmane.linux.distributions.nixos/13447).
* If staging is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days, merge into master, then resume development on staging. [Keep an eye on the staging evaluations here](http://hydra.nixos.org/jobset/nixpkgs/staging#tabs-evaluations).
* When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people installation forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.
* 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.