Add MAINTAINERS file
Add a Linux style MAINTAINERS file and the get_maintainer.pl script from the Linux kernel source (adapted to work in the coreboot source tree) Change-Id: I983e30c20c371d238cfa7c0a074587b731387c63 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/10021 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
This commit is contained in:
parent
0ff13d97d1
commit
c6e1f8aa12
|
@ -0,0 +1,143 @@
|
|||
|
||||
|
||||
List of maintainers and how to submit coreboot changes
|
||||
|
||||
Please try to follow the guidelines below. This will make things
|
||||
easier on the maintainers. Not all of these guidelines matter for every
|
||||
trivial patch so apply some common sense.
|
||||
|
||||
1. Always _test_ your changes, however small, on at least 1 or
|
||||
2 people, preferably many more.
|
||||
|
||||
2. Try to release a few ALPHA test versions to gerrit. Announce
|
||||
them onto the coreboot mailing list and IRC channel and await
|
||||
results. This is especially important on coreboot core changes,
|
||||
but also for device drivers, because often that's the only way
|
||||
you will find things like the fact revision 3 chipset needs
|
||||
a magic fix you didn't know about, or some clown changed the
|
||||
chips on a board and not its name. (Don't laugh!)
|
||||
|
||||
3. Make sure your changes compile correctly in multiple
|
||||
configurations. In particular check that changes work for all
|
||||
boards in the tree (use abuild!)
|
||||
|
||||
4. When you are happy with a change make it generally available for
|
||||
testing in gerrit and await feedback.
|
||||
|
||||
5. Make your patch available through coreboot's gerrit code review
|
||||
system, and add the relevant maintainer from this list as a code
|
||||
reviewer. Be prepared to get your changes sent back with seemingly
|
||||
silly requests about formatting and variable names. These aren't
|
||||
as silly as they seem. One job the maintainers do is to keep
|
||||
things looking the same. Sometimes this means that the clever
|
||||
hack in your mainboard or chipset to get around a problem actually
|
||||
needs to become a generalized coreboot feature ready for next time.
|
||||
|
||||
PLEASE check your patch with the automated style checker
|
||||
(util/lint/checkpatch.pl) to catch trival style violations.
|
||||
See http://coreboot.org/Coding_Style for guidance here.
|
||||
|
||||
PLEASE add the maintainers that are generated by
|
||||
util/scripts/get_maintainer.pl as reviewers. The results returned
|
||||
by the script will be best if you have git installed and are
|
||||
making your changes in a branch derived from coreboot.org's latest
|
||||
git tree.
|
||||
|
||||
PLEASE try to include any credit lines you want added with the
|
||||
patch. It avoids people being missed off by mistake and makes
|
||||
it easier to know who wants adding and who doesn't.
|
||||
|
||||
PLEASE document known bugs. If it doesn't work for everything
|
||||
or does something very odd once a month document it.
|
||||
|
||||
PLEASE remember that submissions must be made under the terms
|
||||
of the OSDL certificate of contribution and should include a
|
||||
Signed-off-by: line. The current version of this "Developer's
|
||||
Certificate of Origin" (DCO) is listed at
|
||||
http://coreboot.org/Development_Guidelines#Sign-off_Procedure.
|
||||
|
||||
6. Make sure you have the right to send any changes you make. If you
|
||||
do changes at work you may find your employer owns the patch
|
||||
not you.
|
||||
|
||||
7. Happy hacking.
|
||||
|
||||
Descriptions of section entries:
|
||||
|
||||
M: Mail patches to: FullName <address@domain>
|
||||
R: Designated reviewer: FullName <address@domain>
|
||||
These reviewers should be CCed on patches.
|
||||
L: Mailing list that is relevant to this area
|
||||
W: Web-page with status/info
|
||||
Q: Patchwork web based patch tracking system site
|
||||
T: SCM tree type and location.
|
||||
Type is one of: git, hg, quilt, stgit, topgit
|
||||
S: Status, one of the following:
|
||||
Supported: Someone is actually paid to look after this.
|
||||
Maintained: Someone actually looks after it.
|
||||
Odd Fixes: It has a maintainer but they don't have time to do
|
||||
much other than throw the odd patch in. See below..
|
||||
Orphan: No current maintainer [but maybe you could take the
|
||||
role as you write your new code].
|
||||
Obsolete: Old code. Something tagged obsolete generally means
|
||||
it has been replaced by a better system and you
|
||||
should be using that.
|
||||
F: Files and directories with wildcard patterns.
|
||||
A trailing slash includes all files and subdirectory files.
|
||||
F: drivers/net/ all files in and below drivers/net
|
||||
F: drivers/net/* all files in drivers/net, but not below
|
||||
F: */net/* all files in "any top level directory"/net
|
||||
One pattern per line. Multiple F: lines acceptable.
|
||||
N: Files and directories with regex patterns.
|
||||
N: [^a-z]tegra all files whose path contains the word tegra
|
||||
One pattern per line. Multiple N: lines acceptable.
|
||||
scripts/get_maintainer.pl has different behavior for files that
|
||||
match F: pattern and matches of N: patterns. By default,
|
||||
get_maintainer will not look at git log history when an F: pattern
|
||||
match occurs. When an N: match occurs, git log history is used
|
||||
to also notify the people that have git commit signatures.
|
||||
X: Files and directories that are NOT maintained, same rules as F:
|
||||
Files exclusions are tested before file matches.
|
||||
Can be useful for excluding a specific subdirectory, for instance:
|
||||
F: net/
|
||||
X: net/ipv6/
|
||||
matches all files in and below net excluding net/ipv6/
|
||||
K: Keyword perl extended regex pattern to match content in a
|
||||
patch or file. For instance:
|
||||
K: of_get_profile
|
||||
matches patches or files that contain "of_get_profile"
|
||||
K: \b(printk|pr_(info|err))\b
|
||||
matches patches or files that contain one or more of the words
|
||||
printk, pr_info or pr_err
|
||||
One regex pattern per line. Multiple K: lines acceptable.
|
||||
|
||||
Note: For the hard of thinking, this list is meant to remain in alphabetical
|
||||
order. If you could add yourselves to it in alphabetical order that would be
|
||||
so much easier [Ed]
|
||||
|
||||
Maintainers List (try to look for most precise areas first)
|
||||
|
||||
-----------------------------------
|
||||
|
||||
RISC-V ARCHITECTURE
|
||||
M: Ronald Minnich <rminnich@gmail.com>
|
||||
S: Maintained
|
||||
F: src/arch/riscv
|
||||
F: src/mainboard/emulation/qemu-riscv
|
||||
|
||||
GOOGLE PANTHER MAINBOARD
|
||||
M: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
||||
S: Supported
|
||||
F: src/mainboard/google/panther
|
||||
|
||||
ATI MACH64 Driver
|
||||
S: Orphan
|
||||
F: drivers/ati/mach64
|
||||
|
||||
THE REST
|
||||
M: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
||||
L: coreboot@coreboot.org
|
||||
T: git http://review.coreboot.org/coreboot
|
||||
S: Buried alive in mainboards
|
||||
F: *
|
||||
F: */
|
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue