meta-intel: Clarify and relocate patch submission guidelines

The current location for patch submission guidelines, MAINTAINERS,
doesn't make as much sense for that information as does README, so
move the relevant information there.

The existing patch submission guidelines also aren't as clear and
exhaustive as they could be; this change additionally adds more
detailed expectations for patch submission.

Both files also get a bit of reorganization and a bit more explicit
text describing their purpose.

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
This commit is contained in:
Tom Zanussi 2014-01-14 16:00:35 -06:00 committed by Tom Zanussi
parent 7e1853808c
commit 381f53495e
2 changed files with 87 additions and 19 deletions

View File

@ -1,26 +1,17 @@
This file contains a list of BSP maintainers for the BSPs contained in
the meta-intel repository.
Please submit any patches against meta-intel BSPs 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.
The purpose of this file is to provide contact information for
specific BSPs and other code contained within meta-intel. You should
address questions and patches for a particular BSP or other code to
the appropriate maintainer listed in this file, cc'ing the meta-intel
mailing list. This ensures that your question or patch will be
addressed by the appropriate person, and that it will be seen by other
users who may be facing similar problems or questions.
If you have problems with or questions about a particular BSP, feel
free to contact the maintainer directly (cc:ing the Yocto mailing list
puts it in the archive and helps other people who might have the same
questions in the future), but please try to do the following first:
- look in the Yocto Project Bugzilla
(http://bugzilla.yoctoproject.org/) to see if a problem has
already been reported
- look through recent entries of the meta-intel
(https://lists.yoctoproject.org/pipermail/meta-intel/) and Yocto
(https://lists.yoctoproject.org/pipermail/yocto/) mailing list
archives to see if other people have run into similar problems or
had similar questions answered.
Please see the top-level README file for guidelines relating to the
details of submitting patches, reporting problems, or asking questions
about any of the BSPs or other recipes contained within meta-intel.
Descriptions of section entries:

77
README
View File

@ -5,3 +5,80 @@ This is the location for Intel maintained BSPs.
Please see the README files contained in the individual BSP layers for
BSP-specific information.
If you have problems with or questions about a particular BSP, please
contact the maintainer listed in the MAINTAINERS file directly (cc:ing
the Yocto mailing list puts it in the archive and helps other people
who might have the same questions in the future), but please try to do
the following first:
- look in the Yocto Project Bugzilla
(http://bugzilla.yoctoproject.org/) to see if a problem has
already been reported
- look through recent entries of the meta-intel
(https://lists.yoctoproject.org/pipermail/meta-intel/) and Yocto
(https://lists.yoctoproject.org/pipermail/yocto/) mailing list
archives to see if other people have run into similar problems or
had similar questions answered.
If you believe you have encountered a bug, you can open a new bug and
enter the details in the Yocto Project Bugzilla
(http://bugzilla.yoctoproject.org/). If you're relatively certain
that it's a bug against the BSP itself, please use the 'Yocto Project
Components: BSPs | meta-intel' category for the bug; otherwise, please
submit the bug against the most likely category for the problem - if
you're wrong, it's not a big deal and the bug will be recategorized
upon triage.
Guidelines for submitting patches
=================================
Please submit any patches against meta-intel BSPs 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 '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' 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.