aboutsummaryrefslogtreecommitdiffstats
path: root/meta-dpdk/README
diff options
context:
space:
mode:
Diffstat (limited to 'meta-dpdk/README')
-rw-r--r--meta-dpdk/README85
1 files changed, 85 insertions, 0 deletions
diff --git a/meta-dpdk/README b/meta-dpdk/README
new file mode 100644
index 00000000..6563ff9f
--- /dev/null
+++ b/meta-dpdk/README
@@ -0,0 +1,85 @@
+meta-dpdk
+=========
+
+This README file contains information on building and booting
+meta-intel BSP layers. Please see the corresponding sections below
+for details.
+
+
+Yocto Project Compatible
+========================
+
+The BSPs contained in this layer are compatible with the Yocto Project
+as per the requirements listed here:
+
+ https://www.yoctoproject.org/webform/yocto-project-compatible-registration
+
+
+Dependencies
+============
+
+This layer depends on:
+
+ URI: git://git.openembedded.org/bitbake
+ branch: 1.34
+
+ URI: git://git.openembedded.org/openembedded-core
+ layers: meta
+ branch: rocko
+
+
+Guidelines for submitting patches
+====================================
+
+Please submit any patches against meta-dpdk 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.
+
+There are patch submission scripts available that will, among other
+things, automatically include the repo URL and branch as mentioned.
+Please see the Yocto Project Development Manual sections entitled
+'Using Scripts to Push a Change Upstream and Request a Pull' and
+'Using Email to Submit a Patch' for details.
+
+Regardless of how you submit a patch or patchset, the patches should
+at minimum follow the suggestions outlined in the 'Submitting a Change
+to the Yocto Project' section 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' in meta-intel will provide you with many
+examples of good example commits if you have questions about any
+aspect of the preferred format.
+
+The meta-intel maintainers will do their best to review and/or pull in
+a patch or patchset within 24 hours of the time it was posted. For
+larger and/or more involved patches and patchsets, the review process
+may take longer.
+
+Please see the meta-intel/MAINTAINERS file for the list of maintainers
+and their specific areas; it's also a good idea to cc: the specific
+maintainer, if applicable.