summaryrefslogtreecommitdiffstats
path: root/meta-qat/README
diff options
context:
space:
mode:
Diffstat (limited to 'meta-qat/README')
-rw-r--r--meta-qat/README85
1 files changed, 85 insertions, 0 deletions
diff --git a/meta-qat/README b/meta-qat/README
new file mode 100644
index 00000000..e43b7fa2
--- /dev/null
+++ b/meta-qat/README
@@ -0,0 +1,85 @@
1meta-qat
2========
3
4This README file contains information on building and booting
5meta-intel BSP layers. Please see the corresponding sections below
6for details.
7
8
9Yocto Project Compatible
10========================
11
12The BSPs contained in this layer are compatible with the Yocto Project
13as per the requirements listed here:
14
15 https://www.yoctoproject.org/webform/yocto-project-compatible-registration
16
17
18Dependencies
19============
20
21This layer depends on:
22
23 URI: git://git.openembedded.org/bitbake
24 branch: 1.34
25
26 URI: git://git.openembedded.org/openembedded-core
27 layers: meta
28 branch: pyro
29
30
31Guidelines for submitting patches
32====================================
33
34Please submit any patches against meta-dpdk to the meta-intel
35mailing list (meta-intel@yoctoproject.org). Also, if your patches are
36available via a public git repository, please also include a URL to
37the repo and branch containing your patches as that makes it easier
38for maintainers to grab and test your patches.
39
40There are patch submission scripts available that will, among other
41things, automatically include the repo URL and branch as mentioned.
42Please see the Yocto Project Development Manual sections entitled
43'Using Scripts to Push a Change Upstream and Request a Pull' and
44'Using Email to Submit a Patch' for details.
45
46Regardless of how you submit a patch or patchset, the patches should
47at minimum follow the suggestions outlined in the 'Submitting a Change
48to the Yocto Project' section in the Yocto Project Development Manual.
49Specifically, they should:
50
51 - Include a 'Signed-off-by:' line. A commit can't legally be pulled
52 in without this.
53
54 - Provide a single-line, short summary of the change. This short
55 description should be prefixed by the BSP or recipe name, as
56 appropriate, followed by a colon. Capitalize the first character
57 of the summary (following the colon).
58
59 - For the body of the commit message, provide detailed information
60 that describes what you changed, why you made the change, and the
61 approach you used.
62
63 - If the change addresses a specific bug or issue that is associated
64 with a bug-tracking ID, include a reference to that ID in your
65 detailed description in the following format: [YOCTO #<bug-id>].
66
67 - Pay attention to line length - please don't allow any particular
68 line in the commit message to stretch past 72 characters.
69
70 - For any non-trivial patch, provide information about how you
71 tested the patch, and for any non-trivial or non-obvious testing
72 setup, provide details of that setup.
73
74Doing a quick 'git log' in meta-intel will provide you with many
75examples of good example commits if you have questions about any
76aspect of the preferred format.
77
78The meta-intel maintainers will do their best to review and/or pull in
79a patch or patchset within 24 hours of the time it was posted. For
80larger and/or more involved patches and patchsets, the review process
81may take longer.
82
83Please see the meta-intel/MAINTAINERS file for the list of maintainers
84and their specific areas; it's also a good idea to cc: the specific
85maintainer, if applicable.