blob: f70724a59e4e367d0024028b2c1c17736c2a97c2 [file] [log] [blame]
Andrew Jefferyd29f9122020-01-09 10:02:03 +10301How to use this list:
2 Find the most specific section entry (described below) that matches where
3 your change lives and add the reviewers (R) and maintainers (M) as
4 reviewers. You can use the same method to track down who knows a particular
5 code base best.
6
7 Your change/query may span multiple entries; that is okay.
8
9 If you do not find an entry that describes your request at all, someone
10 forgot to update this list; please at least file an issue or send an email
11 to a maintainer, but preferably you should just update this document.
12
13Description of section entries:
14
15 Section entries are structured according to the following scheme:
16
17 X: NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>
18 X: ...
19 .
20 .
21 .
22
23 Where REPO_NAME is the name of the repository within the OpenBMC GitHub
24 organization; FILE_PATH is a file path within the repository, possibly with
25 wildcards; X is a tag of one of the following types:
26
27 M: Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
28 if omitted from an entry, assume one of the maintainers from the
29 MAINTAINERS entry.
30 R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>;
31 these people are to be added as reviewers for a change matching the repo
32 path.
33 F: Denotes forked from an external repository; has fields URL.
34
35 Line comments are to be denoted "# SOME COMMENT" (typical shell style
36 comment); it is important to follow the correct syntax and semantics as we
37 may want to use automated tools with this file in the future.
38
39 A change cannot be added to an OpenBMC repository without a MAINTAINER's
40 approval; thus, a MAINTAINER should always be listed as a reviewer.
41
42START OF MAINTAINERS LIST
43-------------------------
44
45M: Jeremy Kerr <jk@ozlabs.org> <jk-!>
46M: Andrew Jeffery <andrew@aj.id.au> <amboar!>