HACKING 3.1 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374
  1. -*- mode: org; coding: utf-8; -*-
  2. #+TITLE: Hacking GNU Guix and Its Incredible Distro
  3. Copyright © 2012, 2013, 2014, 2016, 2017 Ludovic Courtès <ludo@gnu.org>
  4. Copyright © 2015, 2017 Mathieu Lirzin <mthl@gnu.org>
  5. Copyright © 2017 Leo Famulari <leo@famulari.name>
  6. Copyright © 2017 Arun Isaac <arunisaac@systemreboot.net>
  7. Copying and distribution of this file, with or without modification,
  8. are permitted in any medium without royalty provided the copyright
  9. notice and this notice are preserved.
  10. * Contributing
  11. See the manual for useful hacking informations, either by running
  12. info -f doc/guix.info "Contributing"
  13. or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Contributing][web copy of the manual]].
  14. * Commit Access
  15. For frequent contributors, having write access to the repository is
  16. convenient. When you deem it necessary, feel free to ask for it on the
  17. mailing list. When you get commit access, please make sure to follow the
  18. policy below (discussions of the policy can take place on guix-devel@gnu.org.)
  19. Non-trivial patches should always be posted to guix-patches@gnu.org (trivial
  20. patches include fixing typos, etc.) This mailing list fills the
  21. patch-tracking database at [[https://bugs.gnu.org/guix-patches]]; see
  22. "Contributing" in the manual for details.
  23. For patches that just add a new package, and a simple one, it’s OK to commit,
  24. if you’re confident (which means you successfully built it in a chroot setup,
  25. and have done a reasonable copyright and license auditing.) Likewise for
  26. package upgrades, except upgrades that trigger a lot of rebuilds (for example,
  27. upgrading GnuTLS or GLib.) We have a mailing list for commit notifications
  28. (guix-commits@gnu.org), so people can notice. Before pushing your changes,
  29. make sure to run ‘git pull --rebase’.
  30. All commits that are pushed to the central repository on Savannah must be
  31. signed with an OpenPGP key, and the public key should be uploaded to your user
  32. account on Savannah and to public key servers, such as ‘pgp.mit.edu’. To
  33. configure Git to automatically sign commits, run:
  34. git config commit.gpgsign true
  35. git config user.signingkey CABBA6EA1DC0FF33
  36. You can prevent yourself from accidentally pushing unsigned commits to
  37. Savannah by using the pre-push Git hook called located at ‘etc/git/pre-push’:
  38. cp etc/git/pre-push .git/hooks/pre-push
  39. When pushing a commit on behalf of somebody else, please add a Signed-off-by
  40. line at the end of the commit log message (e.g. with ‘git am --signoff’).
  41. This improves tracking of who did what.
  42. For anything else, please post to guix-patches@gnu.org and leave time for a
  43. review, without committing anything. If you didn’t receive any reply
  44. after two weeks, and if you’re confident, it’s OK to commit.
  45. That last part is subject to being adjusted, allowing individuals to commit
  46. directly on non-controversial changes on parts they’re familiar with.
  47. * Using emacs-debbugs
  48. Bug reports and patches are tracked using debbugs. If you are on emacs, you
  49. can use emacs-debbugs.
  50. List all open bug reports on guix-patches with
  51. C-u M-x debbugs-gnu <RET> <RET> guix-patches <RET> n y