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