| # Below lists the current bmcweb maintainers. bmcweb is used in a number of |
| # different contexts, and is one of the few nearly-universally used core |
| # components in OpenBMC. As such, given the severe consequences of mistakes |
| # made within the codebase, maintainers on this list are expected to: |
| # - Have a solid understanding of the bmcweb core code, and how it's used. |
| # |
| # - Have access to at least one upstream platform to test relevant patchsets. |
| # |
| # - Help to manage the orderly merging of patchsets onto master through review. |
| # It is expected that bmcweb maintainers participate on a majority of code |
| # reviews, and although maintainers may work with each other to segment the |
| # responsibilities into sub-parts the codebase, it is expected that maintainers |
| # should be capable of reviewing all code in all modules if the need arises. |
| # |
| # - Provide help in testing and triage of cross-platform issues that arise as a |
| # result of merging new features. |
| # |
| # - Have an in-depth understanding of the Redfish standard, its constraints in |
| # how it interacts with OpenBMC, and how the bmcweb implementation compares to |
| # other Redfish instances and how changes effect compatibility with other |
| # Redfish services compatibility. |
| # |
| # - Be capable of, and have a track record of posing questions, clarifications, |
| # and specification changes to [DMTF](https://www.dmtf.org/standards/redfish) |
| # for resources implemented within the Redfish standard. bmcweb maintainers |
| # regularly attend the Redfish specification meetings to have a handle on |
| # "intent" behind Redfish APIs. In many cases, the role of the maintainer |
| # requires knowing when a Redfish resource is underspecified, and direct people |
| # to the standard before their changes can be accepted. |
| # |
| # - Have an understanding of, and track record of executing the various test |
| # harnesses that bmcweb needs to pass, listed in CLIENTS.md, and at least a |
| # rudimentary understanding of their requirements, and limitations. |
| # |
| # - Have an understanding of DBus and the specific implementations of sdbusplus |
| # APIs that bmcweb uses, and their limitations in versioning, consistency, and |
| # general implementation completeness. |
| # |
| # - Join and answer questions of the #bmcweb-and-redfish channel within |
| # discord. |
| # |
| # - Join and answer architecture queries posed to the mailing list concerning |
| # bmcweb. |
| # |
| # - Be capable of responding to CVE queries forwarded from the |
| # [openbmc-security-response-team] |
| # (https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md). |
| # Considering that in most implementations of the OpenBMC security model, |
| # bmcweb is the primary attacker/client facing application on the network, it |
| # is expected that a number of potential CVEs will be posted, for which bmcweb |
| # forms a component of the alleged attack. Maintainers should be prepared to |
| # respond to such requests in the timeframe required by the CVE process, and |
| # ideally should have a track record of doing it in the past. |
| # |
| # - Understand the webui variants (webui-vue and phosphor-webui) that bmcweb |
| # can optionally host, its use cases, and how they differ from "normal" client |
| # based use cases, as well as an understanding of hosting web services in |
| # general. |
| # |
| # If you believe you meet the qualifications for the above, please open a |
| # patchset, adding your name to the list below, documenting some evidence of |
| # the above requirements being met, and the existing maintainers will happily |
| # add you to the list. |
| |
| owners: |
| - ed@tanous.net |
| - gmills@linux.vnet.ibm.com |
| |
| |
| # The below specifies a list of reviewers and interested parties that should be |
| # included on code reviews to stay informed of progress. |
| |
| reviewers: |
| - krzysztof.grobelny@intel.com |
| - nanzhoumails@gmail.com |
| |
| matchers: |
| # unit tests |
| - suffix: _test.cpp |
| owners: |
| - nanzhoumails@gmail.com |
| |
| # Redfish schemas |
| - exact: redfish-core/include/query.hpp |
| owners: |
| - nanzhoumails@gmail.com |
| - exact: redfish-core/include/utils/query_param.hpp |
| owners: |
| - nanzhoumails@gmail.com |
| - exact: redfish-core/lib/certificate_service.hpp |
| owners: |
| - nanzhoumails@gmail.com |
| - exact: redfish-core/lib/log_services.hpp |
| owners: |
| - nanzhoumails@gmail.com |
| - exact: redfish-core/lib/memory.hpp |
| owners: |
| - nanzhoumails@gmail.com |
| - exact: redfish-core/lib/sensors.hpp |
| owners: |
| - nanzhoumails@gmail.com |
| - krzysztof.grobelny@intel.com |
| - exact: redfish-core/lib/event_service.hpp |
| owners: |
| - krzysztof.grobelny@intel.com |
| - exact: redfish-core/lib/power.hpp |
| owners: |
| - krzysztof.grobelny@intel.com |
| - exact: redfish-core/lib/thermal.hpp |
| owners: |
| - krzysztof.grobelny@intel.com |
| - exact: redfish-core/lib/virtual_media.hpp |
| owners: |
| - krzysztof.grobelny@intel.com |
| |