diff options
| author | Ludovic Courtès <ludo@gnu.org> | 2014-05-11 12:11:09 +0200 |
|---|---|---|
| committer | Ludovic Courtès <ludo@gnu.org> | 2014-05-11 13:35:31 +0200 |
| commit | d0c64188b68cceb93e6a61eba123dac5e47e2c0f (patch) | |
| tree | b33e96e5bb5a48b46df2f5f43effc7ce5116792a /HACKING | |
| parent | af8a56b8a292bb06ac48779e9f0494519617e7d0 (diff) | |
| download | patches-d0c64188b68cceb93e6a61eba123dac5e47e2c0f.tar patches-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-- | HACKING | 3 |
1 files changed, 2 insertions, 1 deletions
@@ -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’. |