You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
106 lines
4.4 KiB
106 lines
4.4 KiB
The project home is http://elfutils.org/ |
|
|
|
The current elfutils source code can be checked out with |
|
git clone git://sourceware.org/git/elfutils.git |
|
|
|
The developer mailinglist to send patches to is |
|
elfutils-devel@sourceware.org. |
|
https://sourceware.org/ml/elfutils-devel/ |
|
|
|
To subscribe send an email to elfutils-devel-subscribe@sourceware.org |
|
Or use the form at https://sourceware.org/lists.html#ml-requestor |
|
|
|
Please supply patches using git format-patch or using git send-email. |
|
|
|
Sign your work |
|
|
|
To facilitate tracking of who did what, we've adopted a "sign-off" |
|
procedure for patches based on the procedure used by the Linux kernel |
|
project. |
|
|
|
The sign-off is a simple line at the end of the explanation for the |
|
patch, which certifies that you wrote it or otherwise have the right |
|
to pass it on as a patch under an appropriate license. The rules are |
|
pretty simple: if you can certify the below: |
|
|
|
Developer's Certificate of Origin |
|
|
|
By making a contribution to this project, I certify that: |
|
|
|
(a) The contribution was created in whole or in part by me, |
|
and I have the right to submit the contribution under each |
|
license indicated in, or otherwise designated as being |
|
applicable to, the file. |
|
|
|
(b) The contribution was provided directly to me by some other |
|
person who certified (a), and I have not modified it. |
|
|
|
(c) I understand and agree that the project and the |
|
contribution are public and that a record of the |
|
contribution (including all personal information I submit |
|
with it, including my sign-off) is maintained indefinitely |
|
and may be redistributed. |
|
|
|
then you just add a line saying |
|
|
|
Signed-off-by: Random J Developer <random@developer.example.org> |
|
|
|
using your real name (sorry, no pseudonyms or anonymous contributions.) |
|
|
|
git commit --signoff will add such a Signed-off-by line at the end of |
|
the commit log message for you. |
|
|
|
The ideal patch contains a ChangeLog entry and a test case for the |
|
bug fixed or feature added. |
|
|
|
The testsuite (make check) is expected to have zero failing tests. |
|
Do not knowingly add tests that FAIL. If there are architectures or |
|
configurations where a tests is not supported make sure they are |
|
skipped instead of failing. Adding "exit 77" in the test shell wrapper |
|
indicates that a test was SKIPPED. |
|
|
|
We do allow binaries in the testsuite for tests that only need to |
|
read ELF or DWARF data and if generating the data in the testcase |
|
itself is difficult or would be architecture specific. |
|
The binaries should be bzip2 compressed. Add a note in the test |
|
wrapper run-<testcase>.sh script how to regenerate the binary. |
|
|
|
After sending your patch to the mailinglist one of the committers |
|
to the project will review it, give feedback, and if perfect they |
|
will commit it for you. |
|
|
|
You can become a maintainer/committer yourself after you have provided |
|
at least a handful of accepted patches and agree to the guidelines in |
|
this document for creating, reviewing, accepting and committing patches. |
|
|
|
To become a committer you need a sourceware account: |
|
https://sourceware.org/cgi-bin/pdw/ps_form.cgi |
|
Upload a SSH public key and have an existing maintainer sponsor you |
|
for the elfutils group. |
|
|
|
committers can push patches through: |
|
ssh://<user>@sourceware.org/git/elfutils.git |
|
|
|
The current webpages published at https://sourceware.org/elfutils/ |
|
can be checked out with: |
|
git clone ssh://<user>@sourceware.org/git/elfutils-htdocs.git |
|
Patches should also be posted to the mailinglist. |
|
|
|
As a maintainer/committer you should still post patches as described |
|
above. And ideally they are reviewed and approved as above. If no |
|
other committer has reviewed or objected to your patch for a week |
|
you may use your own judgement whether you ping your patch or push |
|
it after "self-review". If you do, you should post a message to the |
|
mailinglist that the patch has been pushed. |
|
|
|
committers may also create git branches starting with <nickname>/... |
|
patches on these branches are works in progress, so might not be perfect |
|
yet, but should follow the above guidelines as much as possible and should |
|
be aimed at integration into master. For merging a branch into master |
|
the same process as above should be followed by posting the patches |
|
to the list first. |
|
|
|
committers/maintainers who repeatedly ignore the above guidelines, |
|
are hostile or offensive towards other committers or contributors, |
|
and don't correct their behavior after being asked by other committers |
|
will be removed as maintainer/committer.
|
|
|