CONTRIBUTING

   1 The project homepage is at https://fedorahosted.org/elfutils/
   2
   3 The current elfutils source code can be checked out with
   4 git clone git://git.fedorahosted.org/git/elfutils.git
   5
   6 The developer mailinglist to send patches to is
   7 elfutils-devel@lists.fedorahosted.org.
   8 https://fedorahosted.org/mailman/listinfo/elfutils-devel
   9
  10 Please supply patches using git format-patch or using git send-email.
  11
  12 Sign your work
  13
  14 To facilitate tracking of who did what, we've adopted a "sign-off"
  15 procedure for patches based on the procedure used by the Linux kernel
  16 project.
  17
  18 The sign-off is a simple line at the end of the explanation for the
  19 patch, which certifies that you wrote it or otherwise have the right
  20 to pass it on as a patch under an appropriate license. The rules are
  21 pretty simple: if you can certify the below:
  22
  23         Developer's Certificate of Origin
  24
  25         By making a contribution to this project, I certify that:
  26
  27         (a) The contribution was created in whole or in part by me,
  28             and I have the right to submit the contribution under each
  29             license indicated in, or otherwise designated as being
  30             applicable to, the file.
  31
  32         (b) The contribution was provided directly to me by some other
  33             person who certified (a), and I have not modified it.
  34
  35         (c) I understand and agree that the project and the
  36             contribution are public and that a record of the
  37             contribution (including all personal information I submit
  38             with it, including my sign-off) is maintained indefinitely
  39             and may be redistributed.
  40
  41 then you just add a line saying
  42
  43 Signed-off-by: Random J Developer <random@developer.example.org>
  44
  45 using your real name (sorry, no pseudonyms or anonymous contributions.)
  46
  47 git commit --signoff will add such a Signed-off-by line at the end of
  48 the commit log message for you.
  49
  50 The ideal patch contains a ChangeLog entry and a test case for the
  51 bug fixed or feature added.
  52
  53 The testsuite (make check) is expected to have zero failing tests.
  54 Do not knowingly add tests that FAIL. If there are architectures or
  55 configurations where a tests is not supported make sure they are
  56 skipped instead of failing. Adding "exit 77" in the test shell wrapper
  57 indicates that a test was SKIPPED.
  58
  59 We do allow binaries in the testsuite for tests that only need to
  60 read ELF or DWARF data and if generating the data in the testcase
  61 itself is difficult or would be architecture specific.
  62 The binaries should be bzip2 compressed. Add a note in the test
  63 wrapper run-<testcase>.sh script how to regenerate the binary.
  64
  65 After sending your patch to the mailinglist one of the committers
  66 to the project will review it, give feedback, and if perfect they
  67 will commit it for you.
  68
  69 The current maintainers/committers can be found at:
  70 https://admin.fedoraproject.org/accounts/group/members/gitelfutils/*
  71
  72 You can become a maintainer/committer yourself after you have provided
  73 at least a handful of accepted patches and agree to the guidelines in
  74 this document for creating, reviewing, accepting and committing patches.
  75
  76 To become a committer you need an FAS account at:
  77 https://admin.fedoraproject.org/accounts/
  78 Upload a SSH public key and have an existing maintainer sponsor you
  79 for the Elf Utils Group (gitelfutils).
  80
  81 committers can push patches through:
  82 ssh://<fasname>@git.fedorahosted.org/git/elfutils.git
  83
  84 As a maintainer/committer you should still post patches as described
  85 above. And ideally they are reviewed and approved as above. If no
  86 other committer has reviewed or objected to your patch for a week
  87 you may use your own judgement whether you ping your patch or push
  88 it after "self-review". If you do, you should post a message to the
  89 mailinglist that the patch has been pushed.
  90
  91 committers may also create git branches starting with <fasname>/...
  92 patches on these branches are works in progress, so might not be perfect
  93 yet, but should follow the above guidelines as much as possible and should
  94 be aimed at integration into master. For merging a branch into master
  95 the same process as above should be followed by posting the patches
  96 to the list first.
  97
  98 committers/maintainers who repeatedly ignore the above guidelines,
  99 are hostile or offensive towards other committers or contributors,
 100 and don't correct their behavior after being asked by other committers
 101 will be removed as maintainer/committer.