all: import netsniff-ng 0.5.8-rc0 source

We decided to get rid of the old Git history and start a new one for
several reasons:

 *) Allow / enforce only high-quality commits (which was not the case
    for many commits in the history), have a policy that is more close
    to the one from the Linux kernel. With high quality commits, we
    mean code that is logically split into commits and commit messages
    that are signed-off and have a proper subject and message body.
    We do not allow automatic Github merges anymore, since they are
    total bullshit. However, we will either cherry-pick your patches
    or pull them manually.

 *) The old archive was about ~27MB for no particular good reason.
    This basically derived from the bad decision that also some PDF
    files where stored there. From this moment onwards, no binary
    objects are allowed to be stored in this repository anymore.

The old archive is not wiped away from the Internet. You will still
be able to find it, e.g. on git.cryptoism.org etc.

Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>

1 files changed, 122 insertions, 0 deletions

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
new file mode 100644
index 0000000..fbe72c4
--- /dev/null
+++ b/Documentation/SubmittingPatches
@@ -0,0 +1,122 @@
+Checklist for Patches:
+//////////////////////
+
+Submitting patches should follow this guideline (derived from the Git project):
+
+If you are familiar with upstream Linux kernel development, then you do not
+need to read this file, it's basically the same process.
+
+* Commits:
+
+- make sure to comply with the coding guidelines (see CodingStyle)
+- make commits of logical units
+- check for unnecessary whitespace with "git diff --check" before committing
+- do not check in commented out code or unneeded files
+- the first line of the commit message should be a short description (50
+  characters is the soft limit, see DISCUSSION in git-commit(1)), and should
+  skip the full stop
+- the body should provide a meaningful commit message, which:
+  . explains the problem the change tries to solve, iow, what is wrong with
+    the current code without the change.
+  . justifies the way the change solves the problem, iow, why the result with
+    the change is better.
+  . alternate solutions considered but discarded, if any.
+- describe changes in imperative mood, e.g. "make xyzzy do frotz" instead of
+  "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as
+  if you are giving orders to the codebase to change its behaviour.
+- try to make sure your explanation can be understood without external
+  resources. Instead of giving a URL to a mailing list archive, summarize the
+  relevant points of the discussion.
+- add a "Signed-off-by: Your Name <you@example.com>" line to the commit message
+  (or just use the option "-s" when committing) to confirm that you agree to
+  the Developer's Certificate of Origin (see also
+  http://linux.yyz.us/patch-format.html or below); this is mandatory
+- make sure syntax of man-pages is free of errors: podchecker <tool>.c
+
+* For Patches via GitHub:
+
+- fork the netsniff-ng project on GitHub to your local GitHub account
+  (https://github.com/gnumaniacs/netsniff-ng)
+- make your changes to the latest master branch with respect to the commit
+  section above
+- if you change, add, or remove a command line option or make some other user
+  interface change, the associated documentation should be updated as well.
+- open a pull request on (https://github.com/gnumaniacs/netsniff-ng) and send
+  a notification to the list (netsniff-ng@googlegroups.com) and CC one of the
+  maintainers if (and only if) the patch is ready for inclusion.
+- if your name is not writable in ASCII, make sure that you send off a message
+  in the correct encoding.
+- add a short description what the patch or patchset is about
+
+* For Patches via Mail:
+
+- use "git format-patch -M" to create the patch
+- do not PGP sign your patch
+- do not attach your patch, but read in the mail body, unless you cannot teach
+  your mailer to leave the formatting of the patch alone.
+- be careful doing cut & paste into your mailer, not to corrupt whitespaces.
+- provide additional information (which is unsuitable for the commit message)
+  between the "---" and the diffstat
+- if you change, add, or remove a command line option or make some other user
+  interface change, the associated documentation should be updated as well.
+- if your name is not writable in ASCII, make sure that you send off a message
+  in the correct encoding.
+- send the patch to the list (netsniff-ng@googlegroups.com) and CC one of the
+  maintainers if (and only if) the patch is ready for inclusion. If you use
+  git-send-email(1), please test it first by sending email to yourself.
+
+* What does the 'Signed-off-by' mean?
+
+  It certifies the following (extract from the Linux kernel documentation):
+
+  Developer's Certificate of Origin 1.1
+
+  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 it under the open source license
+      indicated in the file; or
+  (b) The contribution is based upon previous work that, to the best
+      of my knowledge, is covered under an appropriate open source
+      license and I have the right under that license to submit that
+      work with modifications, whether created in whole or in part
+      by me, under the same open source license (unless I am
+      permitted to submit under a different license), as indicated
+      in the file; or
+  (c) The contribution was provided directly to me by some other
+      person who certified (a), (b) or (c) and I have not modified it.
+  (d) I understand and agree that this 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 consistent with
+      this project or the open source license(s) involved.
+
+  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).
+
+* Example commit:
+
+  Please write good git commit messages. A good commit message looks like this:
+
+	Header line: explaining the commit in one line
+
+	Body of commit message is a few lines of text, explaining things
+	in more detail, possibly giving some background about the issue
+	being fixed, etc etc.
+
+	The body of the commit message can be several paragraphs, and
+	please do proper word-wrap and keep columns shorter than about
+	74 characters or so. That way "git log" will show things
+	nicely even when it's indented.
+
+	Reported-by: whoever-reported-it
+	Signed-off-by: Your Name <youremail@yourhost.com>
+
+  where that header line really should be meaningful, and really should be
+  just one line.  That header line is what is shown by tools like gitk and
+  shortlog, and should summarize the change in one readable line of text,
+  independently of the longer explanation.
+
+Note that future (0.5.7 onwards) changelogs will include a summary that is
+generated by 'git shortlog -n'. Hence, that's why we need you to stick to
+the convention.