summaryrefslogtreecommitdiff
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorStefan Reinauer <stefan.reinauer@coreboot.org>2015-04-28 13:42:55 -0700
committerStefan Reinauer <stefan.reinauer@coreboot.org>2015-05-06 19:38:18 +0200
commitc6e1f8aa12c73635fa4889b6c29b9f91bf4a23d5 (patch)
tree3cb91618ef272f57437d98895254a23a20add481 /MAINTAINERS
parent0ff13d97d1a58a1c7e98d81d5c85c6d689b8fb93 (diff)
downloadcoreboot-c6e1f8aa12c73635fa4889b6c29b9f91bf4a23d5.tar.xz
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)
Diffstat (limited to 'MAINTAINERS')
-rw-r--r--MAINTAINERS143
1 files changed, 143 insertions, 0 deletions
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 0000000000..76e4c4c9ff
--- /dev/null
+++ b/MAINTAINERS
@@ -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: */