Permalink
Switch branches/tags
v206 v192 release-16.03-start last-glibc-2.13 black@2016-05-13 binary backups/0.12-release@15293 backups/0.11-release@9315 backups/0.10-release@6725 backups/0.9-release@4651 backups/0.8-release@2530 backups/0.7-release@2398 backups/0.6-release@1775 backups/0.5.1-release@996 backups/0.5-stable@34171 backups/0.5-release@989 backups/xorg-7.5@18179 backups/x86_64-darwin@34171 backups/x-updates@26704 backups/x-updates@22736 backups/usability@34170 backups/udev-173@28837 backups/stdenv-updates@34093 backups/stdenv-updates@32824 backups/stdenv-updates@19858 backups/stdenv-updates@18281 backups/stdenv-updates@15332 backups/stdenv-updates@12144 backups/stdenv-updates@10965 backups/stdenv-updates2@18282 backups/stdenv-updates2@18273 backups/stdenv-updates-merge@10849 backups/stdenv-bootstrap-20100825@23426 backups/stdenv-ada@26758 backups/pure-python@34174 backups/parallel-building-merger@34171 backups/one-click@2549 backups/nixos-pkgs@34170 backups/multitask-builds@34175 backups/multiple-outputs-sandbox@34172 backups/modular-python@26697 backups/master@10848 backups/master@59 backups/mass-update-01@31456 backups/martin@828 backups/martin2@34171 backups/logistics@34171 backups/libpng15@32782 backups/kmod-no-lib-modules@34172 backups/kmod-MODULE_DIR@33576 backups/kernel-config@19023 backups/kde-4.7@34170 backups/glib-2.30@32938 backups/glib-2.30-take2@33502 backups/freebsd-losser@34171 backups/drop-kde4.5@30929 backups/darwin-without-xcode@34172 backups/darwin-updates@34176 backups/cve-2010-3856@34170 backups/armv5tel-linux@18007 18.09 18.09-beta 18.03 18.03-beta 17.09 17.09-beta 17.03 17.03-beta 16.09 16.09-beta 16.03 16.03-beta 15.09 15.09-beta 0.14 0.13 0.12 0.11 0.10 0.9 0.8 0.7 0.6 0.5.1 0.5 0.4 0.3 0.2 0.1
Nothing to show
Find file Copy path
55 lines (35 sloc) 2.31 KB

How to contribute

Note: contributing implies licensing those contributions under the terms of COPYING, which is an MIT-like license.

Opening issues

  • Make sure you have a GitHub account
  • Submit an issue - assuming one does not already exist.
    • Clearly describe the issue including steps to reproduce when it is a bug.
    • Include information what version of nixpkgs and Nix are you using (nixos-version or git revision).

Submitting changes

  • Format the commit messages in the following way:

    (pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
    
    (Motivation for change. Additional information.)
    

    For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).

    Examples:

    • nginx: init at 2.0.1

    • firefox: 54.0.1 -> 55.0

    • nixos/hydra: add bazBaz option

      Dual baz behavior is needed to do foo.

    • nixos/nginx: refactor config generation

      The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).

  • meta.description should:

    • Be capitalized.
    • Not start with the package name.
    • Not have a period at the end.
  • meta.license must be set and fit the upstream license.

    • If there is no upstream license, meta.license should default to stdenv.lib.licenses.unfree.
  • meta.maintainers must be set.

See the nixpkgs manual for more details on standard meta-attributes and on how to submit changes to nixpkgs.

Writing good commit messages

In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand why a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.

For package version upgrades and such a one-line commit message is usually sufficient.

Reviewing contributions

See the nixpkgs manual for more details on how to Review contributions.