1How 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: Ed Tanous <ed.tanous@intel.com> <edtanous!> 46M: James Feist <james.feist@intel.com> <jfei!> 47M: Vernon Mauery <veron.mauery@linux.intel.com> <vmauery!> 48