README: add file

Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>

1 files changed, 59 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 0000000..ef5fcf6
--- /dev/null
+++ b/README
@@ -0,0 +1,59 @@
+meta-intel-quark
+================
+
+This is the BSP layer for the Intel Quark as found in the Intel Galileo gen1 &
+gen2 development boards.
+
+Dependencies
+============
+
+This layer depends on:
+
+  URI: git://git.openembedded.org/openembedded-core
+  branch: daisy
+
+Guidelines for submitting patches
+=================================
+
+Please submit any patches to the meta-intel mailing list
+(meta-intel@yoctoproject.org). Also, if your patches are available via a public
+git repository, please also include a URL to the repo and branch containing
+your patches as that makes it easier for maintainers to grab and test your
+patches.
+
+Regardless of how you submit a patch or patchset, the patches should
+at minimum follow the suggestions outlined in the 'How to Submit a
+Change' secion in the Yocto Project Development Manual.  Specifically,
+they should:
+
+  - Include a 'Signed-off-by:' line.  A commit can't legally be pulled
+    in without this.
+
+  - Provide a single-line, short summary of the change.  This short
+    description should be prefixed by the BSP or recipe name, as
+    appropriate, followed by a colon.  Capitalize the first character
+    of the summary (following the colon).
+
+  - For the body of the commit message, provide detailed information
+    that describes what you changed, why you made the change, and the
+    approach you used.
+
+  - If the change addresses a specific bug or issue that is associated
+    with a bug-tracking ID, include a reference to that ID in your
+    detailed description in the following format: [YOCTO #<bug-id>].
+
+  - Pay attention to line length - please don't allow any particular
+    line in the commit message to stretch past 72 characters.
+
+  - For any non-trivial patch, provide information about how you
+    tested the patch, and for any non-trivial or non-obvious testing
+    setup, provide details of that setup.
+
+Doing a quick 'git log' will provide you with many
+examples of good example commits if you have questions about any
+aspect of the preferred format.
+
+The maintainers will do their best to review and/or pull in a patch or patchset
+within 48 hours of the time it was posted. For larger and/or more involved
+patches and patchsets, the review process may take longer.
+