gnu: Add python-sep.
[jackhill/guix/guix.git] / doc / contributing.texi
index 4195cb4..3baedb0 100644 (file)
@@ -166,14 +166,15 @@ 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 @code{make install}.  To do that, you first need to have an environment
-with all the dependencies available (@pxref{Building from Git}), and then
-simply prefix each command with
-@command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
-top build tree of Guix; it is generated by @command{./configure}).
-As an example, here is how you would build the @code{hello} package as
-defined in your working tree (this assumes @command{guix-daemon} is
-already running on your system; it's OK if it's a different version):
+run @code{make install}.  To do that, you first need to have an
+environment with all the dependencies available (@pxref{Building from
+Git}), and then simply prefix each command with @command{./pre-inst-env}
+(the @file{pre-inst-env} script lives in the top build tree of Guix; it
+is generated by running @command{./bootstrap} followed by
+@command{./configure}).  As an example, here is how you would build the
+@code{hello} package as defined in your working tree (this assumes
+@command{guix-daemon} is already running on your system; it's OK if it's
+a different version):
 
 @example
 $ ./pre-inst-env guix build hello
@@ -592,8 +593,8 @@ such as @command{guix package --show} take care of rendering it
 appropriately.
 
 Synopses and descriptions are translated by volunteers
-@uref{https://translationproject.org/domain/guix-packages.html, at the
-Translation Project} so that as many users as possible can read them in
+@uref{https://translate.fedoraproject.org/projects/guix/packages, at
+Weblate} 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.
 
@@ -801,10 +802,10 @@ To prevent namespace collisions we prefix all other Rust packages with the
 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.@: @code{rust-clap-2}), otherwise the version suffix
-should contain both the major and minor version (e.g.@: @code{rust-rand-0.6}).
+package to be used at any given time, so all package definitions should have a
+versioned suffix.  The versioned suffix is the left-most non-zero digit (and
+any leading zeros, of course).  This follows the ``caret'' version scheme
+intended by Cargo.  Examples@: @code{rust-clap-2}, @code{rust-rand-0.6}.
 
 Because of the difficulty in reusing rust packages as pre-compiled inputs for
 other packages the Cargo build system (@pxref{Build Systems,
@@ -1085,10 +1086,12 @@ 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 @code{master} are considered
-@emph{frozen} if there has been a recent evaluation, or there is a
-corresponding @code{-next} branch.  Please ask on the mailing list or
-IRC if unsure where to place a patch.
+When we decide to start building the @code{staging} or
+@code{core-updates} branches, they will be forked and renamed with the
+suffix @code{-frozen}, at which time only bug fixes may be pushed to the
+frozen branches.  The @code{core-updates} and @code{staging} branches
+will remain open to accept patches for the next cycle.  Please ask on
+the mailing list or IRC if unsure where to place a patch.
 @c TODO: It would be good with badges on the website that tracks these
 @c branches.  Or maybe even a status page.