doc: move files around for consistency

Move some of our documentation files, even though they aren't manpages, to
the doc/ directory. This allows the new 'html' make target to manage them.

Signed-off-by: Dan McGee <dan@archlinux.org>

1 files changed, 0 insertions, 98 deletions

diff --git a/submitting-patches b/submitting-patches
deleted file mode 100644
index e6853c5f..00000000
--- a/submitting-patches
+++ /dev/null
@@ -1,98 +0,0 @@
-Pacman - Submitting Patches
-===========================
-
-This document is here mainly to make the job of those who review patches
-easier and is more of a guideline and not a strict set of rules.  However,
-please try to follow as much as you can.
-
-NOTE: Some of this is paraphrased from the kernel documentation's
-"SubmittingPatches" file.
-
-Getting the most recent source
-------------------------------
-
-Patches need to be submitted in GIT format and are best if they are against the
-latest version of the code. There are several helpful tutorials for getting
-started with GIT if you have not worked with it before.
-
-* http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
-* http://wiki.archlinux.org/index.php/Super_Quick_Git_Guide
-
-The pacman code can be fetched using the following command:
-
-    git clone git://projects.archlinux.org/pacman.git
-
-
-Creating your patch
--------------------
-
---
-* use `git commit -s` for creating a commit of your changes.
-
-The -s allows you to credit yourself by adding a "Signed Off By" line to
-indicate who has "signed" the patch - who has approved it.
-
-    Signed-off-by: Aaron Griffin <aaron@archlinux.org>
-
-Please use your real name and email address. Feel free to "scramble" the
-address if you're afraid of spam.
-
-* Describe your patch.
-
-It helps if you describe the overview and goals  of the patch in the git commit
-log.  This allows others to see what you intended so as to compare it to what
-was actually done, and allows better feedback.
-
-* Use `git format-patch` to create patches.
-
-Your commit message will be shown above the patch by default when you will use
-`git-format-patch`, including the signoff line.
---
-
-Submitting your patch
----------------------
-
---
-* Send the patch to the pacman-dev mailing list
-
-The mailing list is the primary queue for review and acceptance.  Here you
-will get feedback, and let me know the details of your patch.
-
-* No MIME, no links, no compression, no attachments.  Just plain text.
-
-Patches should be contained in the actual body of the email.  There are many
-reasons for this.  First, it makes them easier to read with any mail reader,
-it allows easier review "at a glance", and most importantly, it allows people
-to comment on exact lines of the patch in reply emails.
-
-`git send-email` allows you to send git formatted patches in plain text easily
-and is the preferred method for submission to the mailing list.
-
---
-
-After you submit
-----------------
-
---
-* Don't get discouraged
-
-Any feedback you get, positive or negative, has nothing to do with you.  If a
-patch is rejected, try taking the suggestions into account and re-submitting.
-We welcome most submissions here, and some may take a bit longer to get
-looked over than others. If you think your patch got lost in the shuffle,
-send another email to the list in reply to the original asking if anyone has
-looked at it yet.
-
-* Respond to feedback
-
-When you do get feedback, it usually merits a response, whether this be a
-resubmit of the patch with corrections or a follow-up email asking for
-clarifications. When neither of these occurs, don't expect your patch to see
-further review. The all-volunteer staff don't have time to fix up patches that
-aren't their own.
-
---
-
-/////
-vim: set ts=2 sw=2 syntax=asciidoc et:
-/////