| Jason M. Bills | 8aec3bf | 2019-10-11 12:49:27 -0700 | [diff] [blame] | 1 | List of maintainers for libpeci |
| 2 | =============================== |
| 3 | |
| 4 | How to use this list: |
| 5 | Find the most specific section entry (described below) that matches where |
| 6 | your change lives and add the reviewers (R) and maintainers (M) as |
| 7 | reviewers. You can use the same method to track down who knows a particular |
| 8 | code base best. |
| 9 | |
| 10 | Your change/query may span multiple entries; that is okay. |
| 11 | |
| 12 | If you do not find an entry that describes your request at all, someone |
| 13 | forgot to update this list; please at least file an issue or send an email |
| 14 | to a maintainer, but preferably you should just update this document. |
| 15 | |
| 16 | Description of section entries: |
| 17 | |
| 18 | Section entries are structured according to the following scheme: |
| 19 | |
| 20 | X: NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!> |
| 21 | X: ... |
| 22 | . |
| 23 | . |
| 24 | . |
| 25 | |
| 26 | Where REPO_NAME is the name of the repository within the OpenBMC GitHub |
| 27 | organization; FILE_PATH is a file path within the repository, possibly with |
| 28 | wildcards; X is a tag of one of the following types: |
| 29 | |
| 30 | M: Denotes maintainer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; |
| 31 | if omitted from an entry, assume one of the maintainers from the |
| 32 | MAINTAINERS entry. |
| 33 | R: Denotes reviewer; has fields NAME <EMAIL_USERNAME@DOMAIN> <IRC_USERNAME!>; |
| 34 | these people are to be added as reviewers for a change matching the repo |
| 35 | path. |
| 36 | F: Denotes forked from an external repository; has fields URL. |
| 37 | |
| 38 | Line comments are to be denoted "# SOME COMMENT" (typical shell style |
| 39 | comment); it is important to follow the correct syntax and semantics as we |
| 40 | may want to use automated tools with this file in the future. |
| 41 | |
| 42 | A change cannot be added to an OpenBMC repository without a MAINTAINER's |
| 43 | approval; thus, a MAINTAINER should always be listed as a reviewer. |
| 44 | |
| 45 | Change approval rules: |
| 46 | |
| 47 | - Patches must be available for review for a minimum of 48 hours before it |
| 48 | can be submitted. |
| 49 | - Patches must be be approved (+1) by at least 2 maintainers. |
| 50 | - Patches must not have an unresolved -1 vote by any maintainer. |
| 51 | - Patches should have all maintainers added for visibility. |
| 52 | - Patches should include unit tests where possible. |
| 53 | - Feel free to ping on IRC about patches that look good but have not |
| 54 | received +2 |
| 55 | |
| 56 | Design approval rules: |
| 57 | |
| 58 | - Design discussions should be carried out via email with, at minimum, |
| 59 | all maintainers on the thread. It's encouraged to include the |
| 60 | OpenBMC mailing list in the thread as well. |
| 61 | |
| 62 | START OF MAINTAINERS LIST |
| 63 | ------------------------- |
| 64 | |
| 65 | M: Jason Bills <jason.m.bills@linux.intel.com> <jmbills!> |