diff options
| author | Ed Tanous <edtanous@google.com> | 2022-06-28 18:35:47 +0300 |
|---|---|---|
| committer | Ed Tanous <ed@tanous.net> | 2022-08-17 20:26:19 +0300 |
| commit | b0d3a8562bb11ac9279aa234ce60cf619b64ca6a (patch) | |
| tree | bd776f6b8163748d3713a151a29090d6ef6f922e | |
| parent | 17dcc312e534b33c2ea18a1dbf287e30ea79cfb5 (diff) | |
| download | bmcweb-b0d3a8562bb11ac9279aa234ce60cf619b64ca6a.tar.xz | |
Section out the maintainership of bmcweb
As bmcweb grows, it's important that we distribute the load amongst the
available community. This commit pivots slightly from our usual process
of giving full repo maintainership to a small list of one or two people,
and instead proposes passing out smaller pieces of maintainership. The
hope is that over time, these maintainers can grow into owning larger
portions of the stack.
In this way, we can increase our breadth of available maintainers for
the things that are straightforward, like adding new redfish schemas or
doing migrations, while still keeping a few core maintainers responsible
for the core.
I've reached out to both Krzysztof and Nan, and asked them which pieces
they feel that they're comfortable maintaining, and I've added all
components they listed to the OWNERS files. Each has a track record of
doing reviews in upstream, and given that Gunnar and myself will still
be present and active, this seems like a good thing for the project
overall.
The specific sections of maintainership for each person is laid out in
the OWNERS file, and we can modify over time as each person gets more
experience in reviewing and testing.
The expectations are that for the files explicitly listed, these new
maintainers will be able to handle all reviews that touch those sections
of functionality (including reviews not yet merged). Please continue to
communicate as you have previously.
To those being added, it is expected that if there are core issues
brought up in the modules that you maintain, you escalate them to the
entire group of maintainers, and remain active on our communication
channels. In the past, we've had significant issues where individual
modules tried to implement generalized solutions in a handler-specific
way, and while most of that has been cleaned up, it caused significant
thrash. Lets try to avoid that going forward.
I look forward to working with both of you more.
Change-Id: I7750a12703af68fc82f84a0e22496dabca582208
Signed-off-by: Ed Tanous <edtanous@google.com>
| -rw-r--r-- | OWNERS | 26 |
1 files changed, 26 insertions, 0 deletions
@@ -73,3 +73,29 @@ owners: reviewers: - krzysztof.grobelny@intel.com - nanzhoumails@gmail.com + +matchers: +# unit tests +- suffix: _test.cpp + owners: + nanzhoumails@gmail.com + +# Redfish schemas +- exact: redfish-core/lib/certificate_service.hpp + nanzhoumails@gmail.com +- exact: redfish-core/lib/log_service.hpp + nanzhoumails@gmail.com +- exact: redfish-core/lib/memory.hpp + nanzhoumails@gmail.com +- exact: redfish-core/lib/sensors.hpp + nanzhoumails@gmail.com + krzysztof.grobelny@intel.com +- exact: redfish-core/lib/event_service.hpp + krzysztof.grobelny@intel.com +- exact: redfish-core/lib/power.hpp + krzysztof.grobelny@intel.com +- exact: redfish-core/lib/thermal.hpp + krzysztof.grobelny@intel.com +- exact: redfish-core/lib/virtual_media.hpp + krzysztof.grobelny@intel.com + |