We‘re really glad you’re interested in contributing to nix! This document has a few pointers and guidelines to help get you started.
To have a welcoming and inclusive project, nix uses the Rust project's Code of Conduct. All contributors are expected to follow it.
We use GitHub's issue tracker.
Before submitting a new bug report, please search existing issues to see if there's something related. If not, just open a new issue!
As a reminder, the more information you can give in your issue, the easier it is to figure out how to fix it. For nix, this will likely include the OS and version, and the architecture.
If you'd like a new API or feature added, please open a new issue requesting it. As with reporting a bug, the more information you can provide, the better.
We use labels to help manage issues. The structure is modeled after Rust's issue labeling scheme:
GitHub pull requests are the primary mechanism we use to change nix. GitHub itself has some great documentation on using the Pull Request feature. We use the ‘fork and pull’ model described there.
Please make pull requests against the master branch.
If you change the API by way of adding, removing or changing something or if you fix a bug, please add an appropriate note to the change log. We follow the conventions of Keep A CHANGELOG.
nix has a test suite that you can run with cargo test. Ideally, we'd like pull requests to include tests where they make sense. For example, when fixing a bug, add a test that would have failed without the fix.
After you've made your change, make sure the tests pass in your development environment. We also have continuous integration set up on Travis-CI, which might find some issues on other platforms. The CI will run once you open a pull request.
There is also infrastructure for running tests for other targets locally. More information is available in the CI Readme.
Sometimes there are features that cannot be tested in the CI environment. To stop a test from running under CI, add #[cfg_attr(travis, ignore)] to it. Please include a comment describing the reason it shouldn't run under CI, and a link to an upstream issue if possible!
All pull requests are merged via bors, an integration bot. After the pull request has been reviewed, the reviewer will leave a comment like
bors r+
to let bors know that it was approved. Then bors will check that it passes tests when merged with the latest changes in the master branch, and merge if the tests succeed.
If you're adding a new API, we have a document with conventions to use throughout the nix project.