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
format-patch sent to the firstname.lastname@example.org mailing list.
This mailing list is backed by a Debbugs instance accessible at
https://bugs.gnu.org/guix-patches, which allows us to keep track
of submissions. 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 in 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:
guix lint package, where package is the name of the new or modified package, and fix any errors it reports (see Invoking guix lint).
guix build package.
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.
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.
guix refresh --list-dependent packagewill 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:
master branch (non-disruptive changes).
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
core-updates branch (may include major and potentially disruptive
changes). This branch is intended to be merged in
2.5 months or so.
All these branches are tracked by our build farm and merged into
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
-next branch. Please ask on the mailing list or
IRC if unsure where to place a patch.
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
ci.guix.info to check whether it obtains the same
result as you did. Better yet: Find another machine that can build it
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.
Examples of unrelated changes include the addition of several packages, or a package update along with fixes to that package.
etc/indent-code.elscript to do that automatically for you (see Formatting Code).
namefield in the URL: it is not very useful and if the name changes, the URL will probably be wrong.
When posting a patch to the mailing list, use ‘[PATCH] …’ as
a subject. You may use your email client or the
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
When a bug is resolved, please close the thread by sending an email to NNNemail@example.com.
When sending a patch series (e.g., using
git send-email), please
first send one message to firstname.lastname@example.org, and then send
subsequent patches to NNN@debbugs.gnu.org to make sure
they are kept together. See
the Debbugs documentation
for more information.