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 65owners: 66- ed@tanous.net 67- gmills@linux.vnet.ibm.com 68 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 73reviewers: 74- krzysztof.grobelny@intel.com 75