aboutsummaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorLudovic Courtès <ludo@gnu.org>2014-05-11 12:11:09 +0200
committerLudovic Courtès <ludo@gnu.org>2014-05-11 13:35:31 +0200
commitd0c64188b68cceb93e6a61eba123dac5e47e2c0f (patch)
treeb33e96e5bb5a48b46df2f5f43effc7ce5116792a /HACKING
parentaf8a56b8a292bb06ac48779e9f0494519617e7d0 (diff)
downloadguix-d0c64188b68cceb93e6a61eba123dac5e47e2c0f.tar
guix-d0c64188b68cceb93e6a61eba123dac5e47e2c0f.tar.gz
doc: Mention upgrades that trigger a lot of rebuilds.
* HACKING (Commit Access): Mention upgrades that trigger a lot rebuilds.
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING3
1 files changed, 2 insertions, 1 deletions
diff --git a/HACKING b/HACKING
index 6600397554..9e47b9703b 100644
--- a/HACKING
+++ b/HACKING
@@ -159,7 +159,8 @@ patches include fixing typos, etc.)
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. We have a mailing list for commit notifications
+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’.