summary refs log tree commit diff
path: root/HACKING
diff options
context:
space:
mode:
authorLudovic Courtès <ludo@gnu.org>2014-05-27 23:19:49 +0200
committerLudovic Courtès <ludo@gnu.org>2014-05-27 23:19:49 +0200
commitaf018f5e0a1b7c67e9f40ca68929bd35b94206d3 (patch)
tree8c3efe66f8ac1f6178357937c0a41c6f5ff8f0f8 /HACKING
parentd84a7be6675bd647931d8eff9134d00dd5a6bd58 (diff)
parent35066aa596931ef84922298c2760ceba69940cd1 (diff)
downloadguix-af018f5e0a1b7c67e9f40ca68929bd35b94206d3.tar.gz
Merge branch 'master' into core-updates
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’.