@code{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:
-
-@example
-make authenticate
-@end example
-
-The first run takes a couple of minutes, but subsequent runs are faster.
-
-@quotation Note
-You are advised to run @command{make authenticate} after every
-@command{git pull} invocation. This ensures you keep receiving valid
-changes to the repository
-@end quotation
-
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
fails, take a look at installation instructions (@pxref{Installation})
or send a message to the @email{guix-devel@@gnu.org, mailing list}.
+From there on, you can authenticate all the commits included in your
+checkout by running:
+
+@example
+make authenticate
+@end example
+
+The first run takes a couple of minutes, but subsequent runs are faster.
+
+@quotation Note
+You are advised to run @command{make authenticate} after every
+@command{git pull} invocation. This ensures you keep receiving valid
+changes to the repository.
+@end quotation
+
@node Running Guix Before It Is Installed
@section Running Guix Before It Is Installed
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
+kernel). It is best to use the full commit identifiers in
@code{origin}s, though, to avoid ambiguities. A typical package
definition may look like this:
@lisp
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
- (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
+ (platforms (lookup-qemu-platforms "arm" "aarch64"))
(guix-support? #t)))
@end lisp
@example
guix build --system=armhf-linux --rounds=2 hello
guix build --system=aarch64-linux --rounds=2 hello
-guix build --system=mips64el-linux --rounds=2 hello
@end example
@item
@item 300 dependent packages or less
@code{master} branch (non-disruptive changes).
-@item between 300 and 1,200 dependent packages
+@item between 300 and 1,800 dependent packages
@code{staging} branch (non-disruptive changes). This branch is intended
-to be merged in @code{master} every 3 weeks or so. Topical changes
+to be merged in @code{master} every 6 weeks or so. Topical changes
(e.g., an update of the GNOME stack) can instead go to a specific branch
(say, @code{gnome-updates}).
-@item more than 1,200 dependent packages
+@item more than 1,800 dependent packages
@code{core-updates} branch (may include major and potentially disruptive
changes). This branch is intended to be merged in @code{master} every
-2.5 months or so.
+6 months or so.
@end table
All these branches are @uref{@value{SUBSTITUTE-SERVER},
@end enumerate
When posting a patch to the mailing list, use @samp{[PATCH] @dots{}} as
-a subject. You may use your email client or the @command{git
-send-email} command (@pxref{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.
+a subject, if your patch is to be applied on a branch other than
+@code{master}, say @code{core-updates}, specify it in the subject like
+@samp{[PATCH core-updates] @dots{}}. You may use your email client or
+the @command{git send-email} command (@pxref{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
@email{@var{NNN}-done@@debbugs.gnu.org}.
@itemize
@item
+@url{https://issues.guix.gnu.org} provides a pleasant
+interface@footnote{The web interface at
+@url{https://issues.guix.gnu.org} is powered by Mumi, a nice piece of
+software written in Guile, and you can help! See
+@url{https://git.elephly.net/gitweb.cgi?p=software/mumi.git}.} to browse
+bug reports and patches, and to participate in discussions;
+@item
@url{https://bugs.gnu.org/guix} lists bug reports;
@item
@url{https://bugs.gnu.org/guix-patches} lists patch submissions.
@end itemize
-You can also access both of these @i{via} the (nicer)
-@url{https://issues.guix.gnu.org} interface@footnote{The web interface
-at @url{https://issues.guix.gnu.org} is powered by Mumi, a nice piece of
-software written in Guile, and you can help! See
-@url{https://git.elephly.net/gitweb.cgi?p=software/mumi.git}.}. To view
-discussions related to issue number @var{n}, go to
-@indicateurl{https://issues.guix.gnu.org/issue/@var{n}} or
+To view discussions related to issue number @var{n}, go to
+@indicateurl{https://issues.guix.gnu.org/@var{n}} or
@indicateurl{https://bugs.gnu.org/@var{n}}.
If you use Emacs, you may find it more convenient to interact with
with @command{git am --signoff}. This improves tracking of who did
what.
+When adding channel news entries (@pxref{Channels, Writing Channel
+News}), make sure they are well-formed by running the following command
+right before pushing:
+
+@example
+make check-channel-news
+@end example
+
For anything else, please post to @email{guix-patches@@gnu.org} and
leave time for a review, without committing anything (@pxref{Submitting
Patches}). If you didn’t receive any reply after two weeks, and if
HCoop / jackhill / guix / guix.git / blobdiff