Add libotr/etc sources

1 files changed, 81 insertions, 0 deletions

diff --git a/libotr/libgpg-error-1.42/doc/HACKING b/libotr/libgpg-error-1.42/doc/HACKING
new file mode 100644
index 0000000..33b56d5
--- /dev/null
+++ b/libotr/libgpg-error-1.42/doc/HACKING
@@ -0,0 +1,81 @@
+# HACKING                                                       -*- org -*-
+#+TITLE: Various hacking notes
+#+STARTUP: showall
+
+* How to contribute
+
+  The following stuff explains some basic procedures you need to
+  follow if you want to contribute code or documentation.
+
+* No more ChangeLog files
+
+  Do not modify any of the ChangeLog files in Libgpg-error.  Starting
+  on December 1st, 2011 we put change information only in the GIT
+  commit log, and generate a top-level ChangeLog file from logs at
+  "make dist" time.  As such, there are strict requirements on the
+  form of the commit log messages.  The old ChangeLog files have all
+  be renamed to ChangeLog-2011
+
+
+* Commit log requirements
+
+  Your commit log should always start with a one-line summary, the
+  second line should be blank, and the remaining lines are usually
+  ChangeLog-style entries for all affected files.  However, it's fine
+  -- even recommended -- to write a few lines of prose describing the
+  change, when the summary and ChangeLog entries don't give enough of
+  the big picture.  Omit the leading TABs that you're used to seeing
+  in a "real" ChangeLog file, but keep the maximum line length at 72
+  or smaller, so that the generated ChangeLog lines, each with its
+  leading TAB, will not exceed 80 columns.
+
+* Commit log keywords
+
+  - GnuPG-bug-id :: Values are comma or space delimited bug numbers
+                    from bug.gnupg.org pertaining to this commit.
+  - Debian-bug-id :: Same as above but from the Debian bug tracker.
+  - CVE-id :: CVE id number pertaining to this commit.
+  - Regression-due-to :: Commit id of the regression fixed by this commit.
+  - Fixes-commit :: Commit id this commit fixes.
+  - Reported-by :: Value is a name or mail address of a bug reporte.
+  - Suggested-by :: Value is a name or mail address of someone how
+                    suggested this change.
+  - Co-authored-by :: Name or mail address of a co-author
+  - Some-comments-by :: Name or mail address of the author of
+                        additional comments (commit log or code).
+  - Proofread-by :: Sometimes used by translation commits.
+  - Signed-off-by :: Name or mail address of the developer
+
+* Sending patches
+
+  - submitting patches, and subsequent discussions around them,
+    happens via the gnupg-devel@gnupg.org public mailing list
+
+  - send your patches to that list, preferably PGP/MIME signed. Make
+    sure to include a mention of 'libgpg-error' in the subject line,
+    the list is used for several different projects
+
+  - if you're working from the git repo, here's a suggested workflow:
+
+    - configure git send-email defaults:
+
+        git config format.subjectPrefix 'PATCH libgpg-error'
+        git config sendemail.to gnupg-devel@gnupg.org
+
+      Note that running ./autogen.sh on a fresh clone will do this for
+      you.
+
+    - hack hack hack
+
+    - commit your changes; group changes into easily-reviewable commit
+      units, feel free to submit several patches at once
+
+    - e.g. if you want to submit a single patch on top of master, do:
+      git send-email --annotate -1
+
+    - e.g. if you have two commits on top of master, do:
+      git send-email --annotate --cover-letter -2
+      (that prompts you for a summary mail to precede your actual
+      patch mails)
+
+    - use --dry-run to test your setup