Contributing
************

This project is a cooperative effort, and we need your help to make it grow!  Please get in touch with us on guix-devel@gnu.org and #guix on the Freenode IRC network.  We welcome ideas, bug reports, patches, and anything that may be helpful to the project.  We particularly welcome help on packaging (see Packaging Guidelines).

We want to provide a warm, friendly, and harassment-free environment, so that anyone can contribute to the best of their abilities.  To this end our project uses a ``Contributor Covenant'', which was adapted from http://contributor-covenant.org/.  You can find a local version in the CODE-OF-CONDUCT file in the source tree.

Contributors are not required to use their legal name in patches and on-line communication; they can use any name or pseudonym of their choice.

Building from Git
=================

If you want to hack Guix itself, it is recommended to use the latest version from the Git repository:

     git clone https://git.savannah.gnu.org/git/guix.git

How do you ensure that you obtained a genuine copy of the repository? Guix itself provides a tool to authenticate your checkout, but you must first make sure this tool is genuine in order to ``bootstrap'' the trust chain.  To do that, run:

     git verify-commit `git log --format=%H build-aux/git-authenticate.scm`

The output must look something like:

     gpg: Signature made Fri 27 Dec 2019 01:27:41 PM CET
     gpg:                using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
     ...
     gpg: Signature made Fri 27 Dec 2019 01:25:22 PM CET
     gpg:                using RSA key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
     ...

... meaning that changes to this file are all signed with key 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 (you may need to fetch this key from a key server, if you have not done it yet).

From there on, you can authenticate all the commits included in your checkout by running:

     make authenticate

The first run takes a couple of minutes, but subsequent runs are faster.

     You are advised to run make authenticate after every git pull invocation.  This ensures you keep receiving valid changes to the repository

The easiest way to set up a development environment for Guix is, of course, by using Guix!  The following command starts a new shell where all the dependencies and appropriate environment variables are set up to hack on Guix:

     guix environment guix --pure

See Invoking guix environment, for more information on that command.

If you are unable to use Guix when building Guix from a checkout, the following are the required packages in addition to those mentioned in the installation instructions (see Requirements).

  * GNU Autoconf (http://gnu.org/software/autoconf/);

  * GNU Automake (http://gnu.org/software/automake/);

  * GNU Gettext (http://gnu.org/software/gettext/);

  * GNU Texinfo (http://gnu.org/software/texinfo/);

  * Graphviz (http://www.graphviz.org/);

  * GNU Help2man (optional) (http://www.gnu.org/software/help2man/).

On Guix, extra dependencies can be added by instead running guix environment with --ad-hoc:

     guix environment guix --pure --ad-hoc help2man git strace

Run ./bootstrap to generate the build system infrastructure using Autoconf and Automake.  If you get an error like this one:

     configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES

it probably means that Autoconf couldn’t find pkg.m4, which is provided by pkg-config.  Make sure that pkg.m4 is available.  The same holds for the guile.m4 set of macros provided by Guile.  For instance, if you installed Automake in /usr/local, it wouldn’t look for .m4 files in /usr/share.  In that case, you have to invoke the following command:

     export ACLOCAL_PATH=/usr/share/aclocal

See Macro Search Path (The GNU Automake Manual), for more information.

Then, run ./configure as usual.  Make sure to pass --localstatedir=DIRECTORY where DIRECTORY is the localstatedir value used by your current installation (see The Store, for information about this).  We recommend to use the value /var.

Finally, you have to invoke make check to run tests (see Running the Test Suite).  If anything fails, take a look at installation instructions (see Installation) or send a message to the mailing list.

Running Guix Before It Is Installed
===================================

In order to keep a sane working environment, you will find it useful to test the changes made in your local source tree checkout without actually installing them.  So that you can distinguish between your ``end-user'' hat and your ``motley'' costume.

To that end, all the command-line tools can be used even if you have not run make install.  To do that, you first need to have an environment with all the dependencies available (see Building from Git), and then simply prefix each command with ./pre-inst-env (the pre-inst-env script lives in the top build tree of Guix; it is generated by ./configure). An example (The -E flag to sudo guarantees that GUILE_LOAD_PATH is correctly set such that guix-daemon and the tools it uses can find the Guile modules they need.):

     $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
     $ ./pre-inst-env guix build hello

Similarly, an example for a Guile session using the Guix modules:

     $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'

     ;;; ("x86_64-linux")

... and for a REPL (see Using Guile Interactively (Guile Reference Manual)):

     $ ./pre-inst-env guile
     scheme@(guile-user)> ,use(guix)
     scheme@(guile-user)> ,use(gnu)
     scheme@(guile-user)> (define snakes
                            (fold-packages
                              (lambda (package lst)
                                (if (string-prefix? "python"
                                                    (package-name package))
                                    (cons package lst)
                                    lst))
                              '()))
     scheme@(guile-user)> (length snakes)
     $1 = 361

The pre-inst-env script sets up all the environment variables necessary to support this, including PATH and GUILE_LOAD_PATH.

Note that ./pre-inst-env guix pull does not upgrade the local source tree; it simply updates the ~/.config/guix/current symlink (see Invoking guix pull).  Run git pull instead if you want to upgrade your local source tree.

The Perfect Setup
=================

The Perfect Setup to hack on Guix is basically the perfect setup used for Guile hacking (see Using Guile in Emacs (Guile Reference Manual)).  First, you need more than an editor, you need Emacs (http://www.gnu.org/software/emacs), empowered by the wonderful Geiser (http://nongnu.org/geiser/).  To set that up, run:

     guix package -i emacs guile emacs-geiser

Geiser allows for interactive and incremental development from within Emacs: code compilation and evaluation from within buffers, access to on-line documentation (docstrings), context-sensitive completion, M-. to jump to an object definition, a REPL to try out your code, and more (see Introduction (Geiser User Manual)).  For convenient Guix development, make sure to augment Guile’s load path so that it finds source files from your checkout:

     ;; Assuming the Guix checkout is in ~/src/guix.
     (with-eval-after-load 'geiser-guile
       (add-to-list 'geiser-guile-load-path "~/src/guix"))

To actually edit the code, Emacs already has a neat Scheme mode.  But in addition to that, you must not miss Paredit (https://www.emacswiki.org/emacs/ParEdit).  It provides facilities to directly operate on the syntax tree, such as raising an s-expression or wrapping it, swallowing or rejecting the following s-expression, etc.

We also provide templates for common git commit messages and package definitions in the etc/snippets directory.  These templates can be used with YASnippet (http://joaotavora.github.io/yasnippet/) to expand short trigger strings to interactive text snippets.  You may want to add the snippets directory to the YAS-SNIPPET-DIRS variable in Emacs.

     ;; Assuming the Guix checkout is in ~/src/guix.
     (with-eval-after-load 'yasnippet
       (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))

The commit message snippets depend on Magit (https://magit.vc/) to display staged files.  When editing a commit message type add followed by TAB to insert a commit message template for adding a package; type update followed by TAB to insert a template for updating a package; type https followed by TAB to insert a template for changing the home page URI of a package to HTTPS.

The main snippet for scheme-mode is triggered by typing package... followed by TAB.  This snippet also inserts the trigger string origin..., which can be expanded further.  The origin snippet in turn may insert other trigger strings ending on ..., which also can be expanded further.

Packaging Guidelines
====================

The GNU distribution is nascent and may well lack some of your favorite packages.  This section describes how you can help make the distribution grow.

Free software packages are usually distributed in the form of source code tarballs---typically tar.gz files that contain all the source files.  Adding a package to the distribution means essentially two things: adding a recipe that describes how to build the package, including a list of other packages required to build it, and adding package metadata along with that recipe, such as a description and licensing information.

In Guix all this information is embodied in package definitions. Package definitions provide a high-level view of the package.  They are written using the syntax of the Scheme programming language; in fact, for each package we define a variable bound to the package definition, and export that variable from a module (see Package Modules). However, in-depth Scheme knowledge is not a prerequisite for creating packages.  For more information on package definitions, see Defining Packages.

Once a package definition is in place, stored in a file in the Guix source tree, it can be tested using the guix build command (see Invoking guix build).  For example, assuming the new package is called gnew, you may run this command from the Guix build tree (see Running Guix Before It Is Installed):

     ./pre-inst-env guix build gnew --keep-failed

Using --keep-failed makes it easier to debug build failures since it provides access to the failed build tree.  Another useful command-line option when debugging is --log-file, to access the build log.

If the package is unknown to the guix command, it may be that the source file contains a syntax error, or lacks a define-public clause to export the package variable.  To figure it out, you may load the module from Guile to get more information about the actual error:

     ./pre-inst-env guile -c '(use-modules (gnu packages gnew))'

Once your package builds correctly, please send us a patch (see Submitting Patches).  Well, if you need help, we will be happy to help you too.  Once the patch is committed in the Guix repository, the new package automatically gets built on the supported platforms by our continuous integration system (SUBSTITUTE-SERVER).

Users can obtain the new package definition simply by running guix pull (see Invoking guix pull).  When SUBSTITUTE-SERVER is done building the package, installing the package automatically downloads binaries from there (see Substitutes).  The only place where human intervention is needed is to review and apply the patch.

Software Freedom
----------------

The GNU operating system has been developed so that users can have freedom in their computing.  GNU is free software, meaning that users have the four essential freedoms (http://www.gnu.org/philosophy/free-sw.html): to run the program, to study and change the program in source code form, to redistribute exact copies, and to distribute modified versions.  Packages found in the GNU distribution provide only software that conveys these four freedoms.

In addition, the GNU distribution follow the free software distribution guidelines (http://www.gnu.org/distros/free-system-distribution-guidelines.html).  Among other things, these guidelines reject non-free firmware, recommendations of non-free software, and discuss ways to deal with trademarks and patents.

Some otherwise free upstream package sources contain a small and optional subset that violates the above guidelines, for instance because this subset is itself non-free code.  When that happens, the offending items are removed with appropriate patches or code snippets in the origin form of the package (see Defining Packages).  This way, guix build --source returns the ``freed'' source rather than the unmodified upstream source.

Package Naming
--------------

A package has actually two names associated with it: First, there is the name of the Scheme variable, the one following define-public.  By this name, the package can be made known in the Scheme code, for instance as input to another package.  Second, there is the string in the name field of a package definition.  This name is used by package management commands such as guix package and guix build.

Both are usually the same and correspond to the lowercase conversion of the project name chosen upstream, with underscores replaced with hyphens.  For instance, GNUnet is available as gnunet, and SDL_net as sdl-net.

We do not add lib prefixes for library packages, unless these are already part of the official project name.  But see Python Modules and Perl Modules for special rules concerning modules for the Python and Perl languages.

Font package names are handled differently, see Fonts.

Version Numbers
---------------

We usually package only the latest version of a given free software project.  But sometimes, for instance for incompatible library versions, two (or more) versions of the same package are needed.  These require different Scheme variable names.  We use the name as defined in Package Naming for the most recent version; previous versions use the same name, suffixed by - and the smallest prefix of the version number that may distinguish the two versions.

The name inside the package definition is the same for all versions of a package and does not contain any version number.

For instance, the versions 2.24.20 and 3.9.12 of GTK+ may be packaged as follows:

     (define-public gtk+
       (package
         (name "gtk+")
         (version "3.9.12")
         ...))
     (define-public gtk+-2
       (package
         (name "gtk+")
         (version "2.24.20")
         ...))

If we also wanted GTK+ 3.8.2, this would be packaged as

     (define-public gtk+-3.8
       (package
         (name "gtk+")
         (version "3.8.2")
         ...))

Occasionally, we package snapshots of upstream's version control system (VCS) instead of formal releases.  This should remain exceptional, because it is up to upstream developers to clarify what the stable release is.  Yet, it is sometimes necessary.  So, what should we put in the version field?

Clearly, we need to make the commit identifier of the VCS snapshot visible in the version string, but we also need to make sure that the version string is monotonically increasing so that guix package --upgrade can determine which version is newer.  Since commit identifiers, notably with Git, are not monotonically increasing, we add a revision number that we increase each time we upgrade to a newer snapshot.  The resulting version string looks like this:

     2.0.11-3.cabba9e
       ^    ^    ^
       |    |    `-- upstream commit ID
       |    |
       |    `--- Guix package revision
       |
     latest upstream version

It is a good idea to strip commit identifiers in the version field to, say, 7 digits.  It avoids an aesthetic annoyance (assuming aesthetics have a role to play here) as well as problems related to OS limits such as the maximum shebang length (127 bytes for the Linux kernel.)  It is best to use the full commit identifiers in origins, though, to avoid ambiguities.  A typical package definition may look like this:

     (define my-package
       (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
             (revision "1"))          ;Guix package revision
         (package
           (version (git-version "0.9" revision commit))
           (source (origin
                     (method git-fetch)
                     (uri (git-reference
                           (url "git://example.org/my-package.git")
                           (commit commit)))
                     (sha256 (base32 "1mbikn..."))
                     (file-name (git-file-name name version))))
           ;; ...
           )))

Synopses and Descriptions
-------------------------

As we have seen before, each package in GNU Guix includes a synopsis and a description (see Defining Packages).  Synopses and descriptions are important: They are what guix package --search searches, and a crucial piece of information to help users determine whether a given package suits their needs.  Consequently, packagers should pay attention to what goes into them.

Synopses must start with a capital letter and must not end with a period.  They must not start with ``a'' or ``the'', which usually does not bring anything; for instance, prefer ``File-frobbing tool'' over ``A tool that frobs files''.  The synopsis should say what the package is---e.g., ``Core GNU utilities (file, text, shell)''---or what it is used for---e.g., the synopsis for GNU grep is ``Print lines matching a pattern''.

Keep in mind that the synopsis must be meaningful for a very wide audience.  For example, ``Manipulate alignments in the SAM format'' might make sense for a seasoned bioinformatics researcher, but might be fairly unhelpful or even misleading to a non-specialized audience.  It is a good idea to come up with a synopsis that gives an idea of the application domain of the package.  In this example, this might give something like ``Manipulate nucleotide sequence alignments'', which hopefully gives the user a better idea of whether this is what they are looking for.

Descriptions should take between five and ten lines.  Use full sentences, and avoid using acronyms without first introducing them. Please avoid marketing phrases such as ``world-leading'', ``industrial-strength'', and ``next-generation'', and avoid superlatives like ``the most advanced''---they are not helpful to users looking for a package and may even sound suspicious.  Instead, try to be factual, mentioning use cases and features.

Descriptions can include Texinfo markup, which is useful to introduce ornaments such as @code or @dfn, bullet lists, or hyperlinks (see Overview (GNU Texinfo)).  However you should be careful when using some characters for example @ and curly braces which are the basic special characters in Texinfo (see Special Characters (GNU Texinfo)).  User interfaces such as guix package --show take care of rendering it appropriately.

Synopses and descriptions are translated by volunteers at the Translation Project (http://translationproject.org/domain/guix-packages.html) so that as many users as possible can read them in their native language.  User interfaces search them and display them in the language specified by the current locale.

To allow xgettext to extract them as translatable strings, synopses and descriptions must be literal strings.  This means that you cannot use string-append or format to construct these strings:

     (package
       ;; ...
       (synopsis "This is translatable")
       (description (string-append "This is " "*not*" " translatable.")))

Translation is a lot of work so, as a packager, please pay even more attention to your synopses and descriptions as every change may entail additional work for translators.  In order to help them, it is possible to make recommendations or instructions visible to them by inserting special comments like this (see xgettext Invocation (GNU Gettext)):

     ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
     (description "ARandR is designed to provide a simple visual front end
     for the X11 resize-and-rotate (RandR) extension. ...")

Python Modules
--------------

We currently package Python 2 and Python 3, under the Scheme variable names python-2 and python as explained in Version Numbers. To avoid confusion and naming clashes with other programming languages, it seems desirable that the name of a package for a Python module contains the word python.

Some modules are compatible with only one version of Python, others with both. If the package Foo compiles only with Python 3, we name it python-foo; if it compiles only with Python 2, we name it python2-foo. If it is compatible with both versions, we create two packages with the corresponding names.

If a project already contains the word python, we drop this; for instance, the module python-dateutil is packaged under the names python-dateutil and python2-dateutil.  If the project name starts with py (e.g. pytz), we keep it and prefix it as described above.

Specifying Dependencies
.......................

Dependency information for Python packages is usually available in the package source tree, with varying degrees of accuracy: in the setup.py file, in requirements.txt, or in tox.ini.

Your mission, when writing a recipe for a Python package, is to map these dependencies to the appropriate type of ``input'' (see inputs).  Although the pypi importer normally does a good job (see Invoking guix import), you may want to check the following check list to determine which dependency goes where.

  * We currently package Python 2 with setuptools and pip installed like Python 3.4 has per default.  Thus you don't need to specify either of these as an input.  guix lint will warn you if you do.

  * Python dependencies required at run time go into propagated-inputs.  They are typically defined with the install_requires keyword in setup.py, or in the requirements.txt file.

  * Python packages required only at build time---e.g., those listed with the setup_requires keyword in setup.py---or only for testing---e.g., those in tests_require---go into native-inputs.  The rationale is that (1) they do not need to be propagated because they are not needed at run time, and (2) in a cross-compilation context, it's the ``native'' input that we'd want.

     Examples are the pytest, mock, and nose test frameworks.  Of course if any of these packages is also required at run-time, it needs to go to propagated-inputs.

  * Anything that does not fall in the previous categories goes to inputs, for example programs or C libraries required for building Python packages containing C extensions.

  * If a Python package has optional dependencies (extras_require), it is up to you to decide whether to add them or not, based on their usefulness/overhead ratio (see guix size).

Perl Modules
------------

Perl programs standing for themselves are named as any other package, using the lowercase upstream name. For Perl packages containing a single class, we use the lowercase class name, replace all occurrences of :: by dashes and prepend the prefix perl-. So the class XML::Parser becomes perl-xml-parser. Modules containing several classes keep their lowercase upstream name and are also prepended by perl-.  Such modules tend to have the word perl somewhere in their name, which gets dropped in favor of the prefix.  For instance, libwww-perl becomes perl-libwww.

Java Packages
-------------

Java programs standing for themselves are named as any other package, using the lowercase upstream name.

To avoid confusion and naming clashes with other programming languages, it is desirable that the name of a package for a Java package is prefixed with java-.  If a project already contains the word java, we drop this; for instance, the package ngsjava is packaged under the name java-ngs.

For Java packages containing a single class or a small class hierarchy, we use the lowercase class name, replace all occurrences of . by dashes and prepend the prefix java-.  So the class apache.commons.cli becomes package java-apache-commons-cli.

Rust Crates
-----------

Rust programs standing for themselves are named as any other package, using the lowercase upstream name.

To prevent namespace collisions we prefix all other Rust packages with the rust- prefix.  The name should be changed to lowercase as appropriate and dashes should remain in place.

In the rust ecosystem it is common for multiple incompatible versions of a package to be used at any given time, so all packages should have a versioned suffix.  If a package has passed version 1.0.0 then just the major version number is sufficient (e.g. rust-clap-2), otherwise the version suffix should contain both the major and minor version (e.g. rust-rand-0.6).

Because of the difficulty in reusing rust packages as pre-compiled inputs for other packages the Cargo build system (see cargo-build-system) presents the #:cargo-inputs and cargo-development-inputs keywords as build system arguments.  It would be helpful to think of these as similar to propagated-inputs and native-inputs.  Rust dependencies and build-dependencies should go in #:cargo-inputs, and dev-dependencies should go in #:cargo-development-inputs.  If a Rust package links to other libraries then the standard placement in inputs and the like should be used.

Care should be taken to ensure the correct version of dependencies are used; to this end we try to refrain from skipping the tests or using #:skip-build? when possible.  Of course this is not always possible, as the package may be developed for a different Operating System, depend on features from the Nightly Rust compiler, or the test suite may have atrophied since it was released.

Fonts
-----

For fonts that are in general not installed by a user for typesetting purposes, or that are distributed as part of a larger software package, we rely on the general packaging rules for software; for instance, this applies to the fonts delivered as part of the X.Org system or fonts that are part of TeX Live.

To make it easier for a user to search for fonts, names for other packages containing only fonts are constructed as follows, independently of the upstream package name.

The name of a package containing only one font family starts with font-; it is followed by the foundry name and a dash - if the foundry is known, and the font family name, in which spaces are replaced by dashes (and as usual, all upper case letters are transformed to lower case). For example, the Gentium font family by SIL is packaged under the name font-sil-gentium.

For a package containing several font families, the name of the collection is used in the place of the font family name. For instance, the Liberation fonts consist of three families, Liberation Sans, Liberation Serif and Liberation Mono. These could be packaged separately under the names font-liberation-sans and so on; but as they are distributed together under a common name, we prefer to package them together as font-liberation.

In the case where several formats of the same font family or font collection are packaged separately, a short form of the format, prepended by a dash, is added to the package name.  We use -ttf for TrueType fonts, -otf for OpenType fonts and -type1 for PostScript Type 1 fonts.

Coding Style
============

In general our code follows the GNU Coding Standards (see GNU Coding Standards).  However, they do not say much about Scheme, so here are some additional rules.

Programming Paradigm
--------------------

Scheme code in Guix is written in a purely functional style.  One exception is code that involves input/output, and procedures that implement low-level concepts, such as the memoize procedure.

Modules
-------

Guile modules that are meant to be used on the builder side must live in the (guix build ...) name space.  They must not refer to other Guix or GNU modules.  However, it is OK for a ``host-side'' module to use a build-side module.

Modules that deal with the broader GNU system should be in the (gnu ...) name space rather than (guix ...).

Data Types and Pattern Matching
-------------------------------

The tendency in classical Lisp is to use lists to represent everything, and then to browse them ``by hand'' using car, cdr, cadr, and co.  There are several problems with that style, notably the fact that it is hard to read, error-prone, and a hindrance to proper type error reports.

Guix code should define appropriate data types (for instance, using define-record-type*) rather than abuse lists.  In addition, it should use pattern matching, via Guile’s (ice-9 match) module, especially when matching lists.

Formatting Code
---------------

When writing Scheme code, we follow common wisdom among Scheme programmers.  In general, we follow the Riastradh's Lisp Style Rules (http://mumble.net/~campbell/scheme/style.txt).  This document happens to describe the conventions mostly used in Guile’s code too.  It is very thoughtful and well written, so please do read it.

Some special forms introduced in Guix, such as the substitute* macro, have special indentation rules.  These are defined in the .dir-locals.el file, which Emacs automatically uses.  Also note that Emacs-Guix provides guix-devel-mode mode that indents and highlights Guix code properly (see Development (The Emacs-Guix Reference Manual)).

If you do not use Emacs, please make sure to let your editor knows these rules.  To automatically indent a package definition, you can also run:

     ./etc/indent-code.el gnu/packages/FILE.scm PACKAGE

This automatically indents the definition of PACKAGE in gnu/packages/FILE.scm by running Emacs in batch mode.  To indent a whole file, omit the second argument:

     ./etc/indent-code.el gnu/services/FILE.scm

If you are editing code with Vim, we recommend that you run :set autoindent so that your code is automatically indented as you type. Additionally, paredit.vim (https://www.vim.org/scripts/script.php?script_id=3998) may help you deal with all these parentheses.

We require all top-level procedures to carry a docstring.  This requirement can be relaxed for simple private procedures in the (guix build ...) name space, though.

Procedures should not have more than four positional parameters.  Use keyword parameters for procedures that take more than four parameters.

Submitting Patches
==================

Development is done using the Git distributed version control system. Thus, access to the repository is not strictly necessary.  We welcome contributions in the form of patches as produced by git format-patch sent to the guix-patches@gnu.org mailing list. Seasoned Guix developers may also want to look at the section on commit access (see Commit Access).

This mailing list is backed by a Debbugs instance, which allows us to keep track of submissions (see Tracking Bugs and Patches).  Each message sent to that mailing list gets a new tracking number assigned; people can then follow up on the submission by sending email to NNN@debbugs.gnu.org, where NNN is the tracking number (see Sending a Patch Series).

Please write commit logs in the ChangeLog format (see Change Logs (GNU Coding Standards)); you can check the commit history for examples.

Before submitting a patch that adds or modifies a package definition, please run through this check list:

 1. If the authors of the packaged software provide a cryptographic signature for the release tarball, make an effort to verify the authenticity of the archive.  For a detached GPG signature file this would be done with the gpg --verify command.

 2. Take some time to provide an adequate synopsis and description for the package.  See Synopses and Descriptions, for some guidelines.

 3. Run guix lint PACKAGE, where PACKAGE is the name of the new or modified package, and fix any errors it reports (see Invoking guix lint).

 4. Make sure the package builds on your platform, using guix build PACKAGE.

 5. We recommend you also try building the package on other supported platforms.  As you may not have access to actual hardware platforms, we recommend using the qemu-binfmt-service-type to emulate them.  In order to enable it, add the following service to the list of services in your operating-system configuration:

          (service qemu-binfmt-service-type
           (qemu-binfmt-configuration
             (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
             (guix-support? #t)))

     Then reconfigure your system.

     You can then build packages for different platforms by specifying the --system option.  For example, to build the "hello" package for the armhf, aarch64, or mips64 architectures, you would run the following commands, respectively:

          guix build --system=armhf-linux --rounds=2 hello
          guix build --system=aarch64-linux --rounds=2 hello
          guix build --system=mips64el-linux --rounds=2 hello

 6. Make sure the package does not use bundled copies of software already available as separate packages.

     Sometimes, packages include copies of the source code of their dependencies as a convenience for users.  However, as a distribution, we want to make sure that such packages end up using the copy we already have in the distribution, if there is one.  This improves resource usage (the dependency is built and stored only once), and allows the distribution to make transverse changes such as applying security updates for a given software package in a single place and have them affect the whole system---something that bundled copies prevent.

 7. Take a look at the profile reported by guix size (see Invoking guix size).  This will allow you to notice references to other packages unwillingly retained.  It may also help determine whether to split the package (see Packages with Multiple Outputs), and which optional dependencies should be used.  In particular, avoid adding texlive as a dependency: because of its extreme size, use texlive-tiny or texlive-union instead.

 8. For important changes, check that dependent package (if applicable) are not affected by the change; guix refresh --list-dependent PACKAGE will help you do that (see Invoking guix refresh).

     Depending on the number of dependent packages and thus the amount of rebuilding induced, commits go to different branches, along these lines:

     300 dependent packages or less
          master branch (non-disruptive changes).

     between 300 and 1,200 dependent packages
          staging branch (non-disruptive changes).  This branch is intended to be merged in master every 3 weeks or so.  Topical changes (e.g., an update of the GNOME stack) can instead go to a specific branch (say, gnome-updates).

     more than 1,200 dependent packages
          core-updates branch (may include major and potentially disruptive changes).  This branch is intended to be merged in master every 2.5 months or so.

     All these branches are tracked by our build farm (SUBSTITUTE-SERVER) and merged into master once everything has been successfully built.  This allows us to fix issues before they hit users, and to reduce the window during which pre-built binaries are not available.

     Generally, branches other than master are considered frozen if there has been a recent evaluation, or there is a corresponding -next branch.  Please ask on the mailing list or IRC if unsure where to place a patch.

 9. Check whether the package's build process is deterministic.  This typically means checking whether an independent build of the package yields the exact same result that you obtained, bit for bit.

     A simple way to do that is by building the same package several times in a row on your machine (see Invoking guix build):

          guix build --rounds=2 my-package

     This is enough to catch a class of common non-determinism issues, such as timestamps or randomly-generated output in the build result.

     Another option is to use guix challenge (see Invoking guix challenge).  You may run it once the package has been committed and built by SUBSTITUTE-SERVER to check whether it obtains the same result as you did.  Better yet: Find another machine that can build it and run guix publish.  Since the remote build machine is likely different from yours, this can catch non-determinism issues related to the hardware---e.g., use of different instruction set extensions---or to the operating system kernel---e.g., reliance on uname or /proc files.

 10. When writing documentation, please use gender-neutral wording when referring to people, such as singular ``they'', ``their'', ``them'' (https://en.wikipedia.org/wiki/Singular_they), and so forth.

 11. Verify that your patch contains only one set of related changes. Bundling unrelated changes together makes reviewing harder and slower.

     Examples of unrelated changes include the addition of several packages, or a package update along with fixes to that package.

 12. Please follow our code formatting rules, possibly running the etc/indent-code.el script to do that automatically for you (see Formatting Code).

 13. When possible, use mirrors in the source URL (see Invoking guix download). Use reliable URLs, not generated ones.  For instance, GitHub archives are not necessarily identical from one generation to the next, so in this case it's often better to clone the repository.  Don't use the name field in the URL: it is not very useful and if the name changes, the URL will probably be wrong.

 14. Check if Guix builds (see Building from Git) and address the warnings, especially those about use of undefined symbols.

 15. Make sure your changes do not break Guix and simulate a guix pull with:

          guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master

When posting a patch to the mailing list, use [PATCH] ... as a subject.  You may use your email client or the git send-email command (see Sending a Patch Series).  We prefer to get patches in plain text messages, either inline or as MIME attachments. You are advised to pay attention if your email client changes anything like line breaks or indentation which could potentially break the patches.

When a bug is resolved, please close the thread by sending an email to NNN-done@debbugs.gnu.org.

Sending a Patch Series
----------------------

When sending a patch series (e.g., using git send-email), please first send one message to guix-patches@gnu.org, and then send subsequent patches to NNN@debbugs.gnu.org to make sure they are kept together.  See the Debbugs documentation (https://debbugs.gnu.org/Advanced.html) for more information.  You can install git send-email with guix install git:send-email.

Tracking Bugs and Patches
=========================

Bug reports and patch submissions are currently tracked using the Debbugs instance at https://bugs.gnu.org.  Bug reports are filed against the guix ``package'' (in Debbugs parlance), by sending email to bug-guix@gnu.org, while patch submissions are filed against the guix-patches package by sending email to guix-patches@gnu.org (see Submitting Patches).

A web interface (actually two web interfaces!) are available to browse issues:

  * https://bugs.gnu.org/guix lists bug reports;

  * https://bugs.gnu.org/guix-patches lists patch submissions.

You can also access both of these via the (nicer) https://issues.guix.gnu.org interface (The web interface at https://issues.guix.gnu.org is powered by Mumi, a nice piece of software written in Guile, and you can help!  See https://git.elephly.net/gitweb.cgi?p=software/mumi.git.).  To view discussions related to issue number N, go to https://issues.guix.gnu.org/issue/N or https://bugs.gnu.org/N.

If you use Emacs, you may find it more convenient to interact with issues using debbugs.el, which you can install with:

     guix install emacs-debbugs

For example, to list all open issues on guix-patches, hit:

     C-u M-x debbugs-gnu RET RET guix-patches RET n y

See Debbugs User Guide, for more information on this nifty tool!

Commit Access
=============

For frequent contributors, having write access to the repository is convenient.  When you deem it necessary, consider applying for commit access by following these steps:

 1. Find three committers who would vouch for you.  You can view the list of committers at https://savannah.gnu.org/project/memberlist.php?group=guix.  Each of them should email a statement to guix-maintainers@gnu.org (a private alias for the collective of maintainers), signed with their OpenPGP key.

     Committers are expected to have had some interactions with you as a contributor and to be able to judge whether you are sufficiently familiar with the project's practices.  It is not a judgment on the value of your work, so a refusal should rather be interpreted as ``let's try again later''.

 2. Send guix-maintainers@gnu.org a message stating your intent, listing the three committers who support your application, signed with the OpenPGP key you will use to sign commits, and giving its fingerprint (see below).  See https://emailselfdefense.fsf.org/en/, for an introduction to public-key cryptography with GnuPG.

 3. Maintainers ultimately decide whether to grant you commit access, usually following your referrals' recommendation.

 4. If and once you've been given access, please send a message to guix-devel@gnu.org to say so, again signed with the OpenPGP key you will use to sign commits (do that before pushing your first commit). That way, everyone can notice and ensure you control that OpenPGP key.

 5. Make sure to read the rest of this section and... profit!

     Maintainers are happy to give commit access to people who have been contributing for some time and have a track record---don't be shy and don't underestimate your work!

     However, note that the project is working towards a more automated patch review and merging system, which, as a consequence, may lead us to have fewer people with commit access to the main repository.  Stay tuned!

If you get commit access, please make sure to follow the policy below (discussions of the policy can take place on guix-devel@gnu.org).

Non-trivial patches should always be posted to guix-patches@gnu.org (trivial patches include fixing typos, etc.).  This mailing list fills the patch-tracking database (see Tracking Bugs and Patches).

For patches that just add a new package, and a simple one, it's OK to commit, if you're confident (which means you successfully built it in a chroot setup, and have done a reasonable copyright and license auditing).  Likewise for package upgrades, except upgrades that trigger a lot of rebuilds (for example, upgrading GnuTLS or GLib).  We have a mailing list for commit notifications (guix-commits@gnu.org), so people can notice.  Before pushing your changes, make sure to run git pull --rebase.

All commits that are pushed to the central repository on Savannah must be signed with an OpenPGP key, and the public key should be uploaded to your user account on Savannah and to public key servers, such as keys.openpgp.org.  To configure Git to automatically sign commits, run:

     git config commit.gpgsign true
     git config user.signingkey CABBA6EA1DC0FF33

You can prevent yourself from accidentally pushing unsigned commits to Savannah by using the pre-push Git hook called located at etc/git/pre-push:

     cp etc/git/pre-push .git/hooks/pre-push

When pushing a commit on behalf of somebody else, please add a Signed-off-by line at the end of the commit log message---e.g., with git am --signoff.  This improves tracking of who did what.

For anything else, please post to guix-patches@gnu.org and leave time for a review, without committing anything (see Submitting Patches).  If you didn’t receive any reply after two weeks, and if you're confident, it's OK to commit.

That last part is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with.

One last thing: the project keeps moving forward because committers not only push their own awesome changes, but also offer some of their time reviewing and pushing other people's changes.  As a committer, you're welcome to use your expertise and commit rights to help other contributors, too!