Squashed 'third_party/elfutils/' content from commit 555e15e
Change-Id: I61cde98949e47e5c8c09c33260de17f30921be79
git-subtree-dir: third_party/elfutils
git-subtree-split: 555e15ebe8bf1eb33d00747173cfc80cc65648a4
diff --git a/CONTRIBUTING b/CONTRIBUTING
new file mode 100644
index 0000000..e3d5a0f
--- /dev/null
+++ b/CONTRIBUTING
@@ -0,0 +1,106 @@
+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.