Ed Tanous | ceeba4f | 2022-05-16 14:59:33 -0700 | [diff] [blame] | 1 | # Below lists the current bmcweb maintainers. bmcweb is used in a number of |
| 2 | # different contexts, and is one of the few nearly-universally used core |
| 3 | # components in OpenBMC. As such, given the severe consequences of mistakes |
| 4 | # made within the codebase, maintainers on this list are expected to: |
| 5 | # - Have a solid understanding of the bmcweb core code, and how it's used. |
| 6 | # |
| 7 | # - Have access to at least one upstream platform to test relevant patchsets. |
| 8 | # |
| 9 | # - Help to manage the orderly merging of patchsets onto master through review. |
| 10 | # It is expected that bmcweb maintainers participate on a majority of code |
| 11 | # reviews, and although maintainers may work with each other to segment the |
| 12 | # responsibilities into sub-parts the codebase, it is expected that maintainers |
| 13 | # should be capable of reviewing all code in all modules if the need arises. |
| 14 | # |
| 15 | # - Provide help in testing and triage of cross-platform issues that arise as a |
| 16 | # result of merging new features. |
| 17 | # |
| 18 | # - Have an in-depth understanding of the Redfish standard, its constraints in |
| 19 | # how it interacts with OpenBMC, and how the bmcweb implementation compares to |
| 20 | # other Redfish instances and how changes effect compatibility with other |
| 21 | # Redfish services compatibility. |
| 22 | # |
| 23 | # - Be capable of, and have a track record of posing questions, clarifications, |
| 24 | # and specification changes to [DMTF](https://www.dmtf.org/standards/redfish) |
| 25 | # for resources implemented within the Redfish standard. bmcweb maintainers |
| 26 | # regularly attend the Redfish specification meetings to have a handle on |
| 27 | # "intent" behind Redfish APIs. In many cases, the role of the maintainer |
| 28 | # requires knowing when a Redfish resource is underspecified, and direct people |
| 29 | # to the standard before their changes can be accepted. |
| 30 | # |
| 31 | # - Have an understanding of, and track record of executing the various test |
| 32 | # harnesses that bmcweb needs to pass, listed in CLIENTS.md, and at least a |
| 33 | # rudimentary understanding of their requirements, and limitations. |
| 34 | # |
| 35 | # - Have an understanding of DBus and the specific implementations of sdbusplus |
| 36 | # APIs that bmcweb uses, and their limitations in versioning, consistency, and |
| 37 | # general implementation completeness. |
| 38 | # |
| 39 | # - Join and answer questions of the #bmcweb-and-redfish channel within |
| 40 | # discord. |
| 41 | # |
| 42 | # - Join and answer architecture queries posed to the mailing list concerning |
| 43 | # bmcweb. |
| 44 | # |
| 45 | # - Be capable of responding to CVE queries forwarded from the |
| 46 | # [openbmc-security-response-team] |
| 47 | # (https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md). |
| 48 | # Considering that in most implementations of the OpenBMC security model, |
| 49 | # bmcweb is the primary attacker/client facing application on the network, it |
| 50 | # is expected that a number of potential CVEs will be posted, for which bmcweb |
| 51 | # forms a component of the alleged attack. Maintainers should be prepared to |
| 52 | # respond to such requests in the timeframe required by the CVE process, and |
| 53 | # ideally should have a track record of doing it in the past. |
| 54 | # |
| 55 | # - Understand the webui variants (webui-vue and phosphor-webui) that bmcweb |
| 56 | # can optionally host, its use cases, and how they differ from "normal" client |
| 57 | # based use cases, as well as an understanding of hosting web services in |
| 58 | # general. |
| 59 | # |
| 60 | # If you believe you meet the qualifications for the above, please open a |
| 61 | # patchset, adding your name to the list below, documenting some evidence of |
| 62 | # the above requirements being met, and the existing maintainers will happily |
| 63 | # add you to the list. |
| 64 | |
Ed Tanous | eaa96da | 2021-02-05 10:50:34 -0800 | [diff] [blame] | 65 | owners: |
| 66 | - ed@tanous.net |
Ed Tanous | eaa96da | 2021-02-05 10:50:34 -0800 | [diff] [blame] | 67 | - gmills@linux.vnet.ibm.com |
Gunnar Mills | 6afb06d | 2021-12-01 13:39:09 -0600 | [diff] [blame] | 68 | |
Ed Tanous | ceeba4f | 2022-05-16 14:59:33 -0700 | [diff] [blame] | 69 | |
| 70 | # The below specifies a list of reviewers and interested parties that should be |
| 71 | # included on code reviews to stay informed of progress. |
| 72 | |
Gunnar Mills | 6afb06d | 2021-12-01 13:39:09 -0600 | [diff] [blame] | 73 | reviewers: |
| 74 | - krzysztof.grobelny@intel.com |
Nan Zhou | 0135854 | 2022-06-24 01:36:23 +0000 | [diff] [blame] | 75 | - nanzhoumails@gmail.com |