Merge branch 'master' into core-updates

1 files changed, 28 insertions, 0 deletions

diff --git a/doc/contributing.texi b/doc/contributing.texi
index c0755bb895..18d891db4e 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -289,6 +289,20 @@ Make sure the package builds on your platform, using @code{guix build
 @var{package}}.
 
 @item
+@cindex bundling
+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.
+
+@item
 Take a look at the profile reported by @command{guix size}
 (@pxref{Invoking guix size}).  This will allow you to notice references
 to other packages unwillingly retained.  It may also help determine
@@ -300,6 +314,13 @@ For important changes, check that dependent package (if applicable) are
 not affected by the change; @code{guix refresh --list-dependent
 @var{package}} will help you do that (@pxref{Invoking guix refresh}).
 
+Packages with roughly 100 dependents or more usually have to be
+committed to a separate branch.  That branch can then be built
+separately by our build farm, and later merged into @code{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.
+
 @item
 @cindex determinism, of build processes
 @cindex reproducible builds, checking
@@ -333,6 +354,13 @@ referring to people, such as
 @uref{https://en.wikipedia.org/wiki/Singular_they, singular
 ``they''@comma{} ``their''@comma{} ``them''}, and so forth.
 
+@item
+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.
+
 @end enumerate
 
 When posting a patch to the mailing list, use @samp{[PATCH] @dots{}} as