blob: bd49c418493f4f6c46418eabaadd9fc65f277cbf [file] [log] [blame]
Stefan Reinauerc6e1f8a2015-04-28 13:42:55 -07001
3 List of maintainers and how to submit coreboot changes
5Please try to follow the guidelines below. This will make things
6easier on the maintainers. Not all of these guidelines matter for every
7trivial patch so apply some common sense.
91. Always _test_ your changes, however small, on at least 1 or
10 2 people, preferably many more.
122. Try to release a few ALPHA test versions to gerrit. Announce
13 them onto the coreboot mailing list and IRC channel and await
14 results. This is especially important on coreboot core changes,
15 but also for device drivers, because often that's the only way
16 you will find things like the fact revision 3 chipset needs
17 a magic fix you didn't know about, or some clown changed the
18 chips on a board and not its name. (Don't laugh!)
203. Make sure your changes compile correctly in multiple
21 configurations. In particular check that changes work for all
22 boards in the tree (use abuild!)
244. When you are happy with a change make it generally available for
25 testing in gerrit and await feedback.
275. Make your patch available through coreboot's gerrit code review
28 system, and add the relevant maintainer from this list as a code
29 reviewer. Be prepared to get your changes sent back with seemingly
30 silly requests about formatting and variable names. These aren't
31 as silly as they seem. One job the maintainers do is to keep
32 things looking the same. Sometimes this means that the clever
33 hack in your mainboard or chipset to get around a problem actually
34 needs to become a generalized coreboot feature ready for next time.
36 PLEASE check your patch with the automated style checker
37 (util/lint/ to catch trival style violations.
38 See for guidance here.
40 PLEASE add the maintainers that are generated by
41 util/scripts/ as reviewers. The results returned
42 by the script will be best if you have git installed and are
43 making your changes in a branch derived from's latest
44 git tree.
46 PLEASE try to include any credit lines you want added with the
47 patch. It avoids people being missed off by mistake and makes
48 it easier to know who wants adding and who doesn't.
50 PLEASE document known bugs. If it doesn't work for everything
51 or does something very odd once a month document it.
53 PLEASE remember that submissions must be made under the terms
54 of the OSDL certificate of contribution and should include a
55 Signed-off-by: line. The current version of this "Developer's
56 Certificate of Origin" (DCO) is listed at
596. Make sure you have the right to send any changes you make. If you
60 do changes at work you may find your employer owns the patch
61 not you.
637. Happy hacking.
65Descriptions of section entries:
67 M: Mail patches to: FullName <address@domain>
68 R: Designated reviewer: FullName <address@domain>
69 These reviewers should be CCed on patches.
70 L: Mailing list that is relevant to this area
71 W: Web-page with status/info
72 Q: Patchwork web based patch tracking system site
73 T: SCM tree type and location.
74 Type is one of: git, hg, quilt, stgit, topgit
75 S: Status, one of the following:
76 Supported: Someone is actually paid to look after this.
77 Maintained: Someone actually looks after it.
78 Odd Fixes: It has a maintainer but they don't have time to do
79 much other than throw the odd patch in. See below..
80 Orphan: No current maintainer [but maybe you could take the
81 role as you write your new code].
82 Obsolete: Old code. Something tagged obsolete generally means
83 it has been replaced by a better system and you
84 should be using that.
85 F: Files and directories with wildcard patterns.
86 A trailing slash includes all files and subdirectory files.
87 F: drivers/net/ all files in and below drivers/net
88 F: drivers/net/* all files in drivers/net, but not below
89 F: */net/* all files in "any top level directory"/net
90 One pattern per line. Multiple F: lines acceptable.
91 N: Files and directories with regex patterns.
92 N: [^a-z]tegra all files whose path contains the word tegra
93 One pattern per line. Multiple N: lines acceptable.
94 scripts/ has different behavior for files that
95 match F: pattern and matches of N: patterns. By default,
96 get_maintainer will not look at git log history when an F: pattern
97 match occurs. When an N: match occurs, git log history is used
98 to also notify the people that have git commit signatures.
99 X: Files and directories that are NOT maintained, same rules as F:
100 Files exclusions are tested before file matches.
101 Can be useful for excluding a specific subdirectory, for instance:
102 F: net/
103 X: net/ipv6/
104 matches all files in and below net excluding net/ipv6/
105 K: Keyword perl extended regex pattern to match content in a
106 patch or file. For instance:
107 K: of_get_profile
108 matches patches or files that contain "of_get_profile"
109 K: \b(printk|pr_(info|err))\b
110 matches patches or files that contain one or more of the words
111 printk, pr_info or pr_err
112 One regex pattern per line. Multiple K: lines acceptable.
114Note: For the hard of thinking, this list is meant to remain in alphabetical
115order. If you could add yourselves to it in alphabetical order that would be
116so much easier [Ed]
118Maintainers List (try to look for most precise areas first)
120 -----------------------------------
123M: Ronald Minnich <>
124S: Maintained
125F: src/arch/riscv
126F: src/mainboard/emulation/qemu-riscv
129M: Stefan Reinauer <>
130S: Supported
131F: src/mainboard/google/panther
133ATI MACH64 Driver
134S: Orphan
135F: drivers/ati/mach64
Stefan Reinauer2e38cc52015-05-06 11:15:38 -0700137LINT SCRIPTS
138M: Patrick Georgi <>
139S: Supported
140F: util/lint/
Patrick Georgi65ff63f2015-05-21 18:54:10 +0200142BUILD SYSTEM
143M: Patrick Georgi <>
144S: Supported
145F: Makefile
146F: *.inc
147F: util/kconfig
148F: util/sconfig
Stefan Reinauerc6e1f8a2015-04-28 13:42:55 -0700150THE REST
151M: Stefan Reinauer <>
153T: git
154S: Buried alive in mainboards
155F: *
156F: */