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 7[email protected]. 8https://sourceware.org/ml/elfutils-devel/ 9 10To subscribe send an email to [email protected] 11Or use the form at https://sourceware.org/mailman/listinfo/elfutils-devel 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 <[email protected]> 47 48using a known identity (sorry, no anonymous contributions.) 49The name you use as your identity should not be an anonymous id 50or false name that misrepresents who you are. 51 52git commit --signoff will add such a Signed-off-by line at the end of 53the commit log message for you. 54 55The ideal patch contains a ChangeLog entry for the commit message and 56a test case for the bug fixed or feature added. 57 58The commit message is expected to start with a one line summary of 59what the patch does, prefixed with the main subdir the patch applies 60to. e.g libelf: Rewind the elf_frob function bar definitions. 61 62Finally please include an ChangeLog entry explicitly listing the files 63and what changed in each of them in the commit message. This will help 64a reviewer understand which changes are expected (and which might be 65accidential). Try to follow the GNU Change Log style: 66https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html 67Note that elfutils previously maintained separate ChangeLog 68files. These are no longer used. All changes should be documented in 69the git commit message. 70 71The testsuite (make check) is expected to have zero failing tests. 72Do not knowingly add tests that FAIL. If there are architectures or 73configurations where a tests is not supported make sure they are 74skipped instead of failing. Adding "exit 77" in the test shell wrapper 75indicates that a test was SKIPPED. 76 77We do allow binaries in the testsuite for tests that only need to 78read ELF or DWARF data and if generating the data in the testcase 79itself is difficult or would be architecture specific. 80The binaries should be bzip2 compressed. Add a note in the test 81wrapper run-<testcase>.sh script how to regenerate the binary. 82 83After sending your patch to the mailinglist one of the committers 84to the project will review it, give feedback, and if perfect they 85will commit it for you. 86 87All patches sent to the mailing list are tracked at 88https://patchwork.sourceware.org/project/elfutils/list/ 89 90To use this from the command line you can use git-pw 91https://patchwork.readthedocs.io/projects/git-pw/en/latest/ 92 93For using it with git-pw use these .git/config settings: 94 [pw] 95 server = https://patchwork.sourceware.org/api/1.2/ 96 project = elfutils 97 token = <hex-token> 98 states = committed,accepted,superseded,deferred,rejected,under-review 99 100If you would like to help maintain the pending patch list your 101patchwork account can be added as maintainer for the elfutils project. 102 103You can become a maintainer/committer yourself after you have provided 104at least a handful of accepted patches and agree to the guidelines in 105this document for creating, reviewing, accepting and committing patches. 106 107To become a committer you need a sourceware account: 108https://sourceware.org/cgi-bin/pdw/ps_form.cgi 109Upload a SSH public key and have an existing maintainer sponsor you 110for the elfutils group. 111 112committers can push patches through: 113ssh://<user>@sourceware.org/git/elfutils.git 114 115The current webpages published at https://sourceware.org/elfutils/ 116can be checked out with: 117git clone ssh://<user>@sourceware.org/git/elfutils-htdocs.git 118Patches should also be posted to the mailinglist. 119 120As a maintainer/committer you should still post patches as described 121above. And ideally they are reviewed and approved as above. If no 122other committer has reviewed or objected to your patch for a week 123you may use your own judgement whether you ping your patch or push 124it after "self-review". If you do, you should post a message to the 125mailinglist that the patch has been pushed. 126 127committers may also create git branches starting with <nickname>/... 128patches on these branches are works in progress, so might not be perfect 129yet, but should follow the above guidelines as much as possible and should 130be aimed at integration into main. For merging a branch into main 131the same process as above should be followed by posting the patches 132to the list first. 133 134Note that a branch starting with <nickname>/try... will be picked up 135by the Sourceware buildbot and can be used to test your patches before 136merging into the main branch: 137https://builder.sourceware.org/buildbot/#/builders?tags=elfutils-try 138 139committers/maintainers who repeatedly ignore the above guidelines, 140are hostile or offensive towards other committers or contributors, 141and don't correct their behavior after being asked by other committers 142will be removed as maintainer/committer. 143