Machine-scope maintainers for OpenBMC

[Andrew Jeffery]

Hello!

I'm wondering whether we should jot down the maintainers of machines
supported by OpenBMC, and if so, where? With respect to the latter, one
candidate might be the MAINTAINERS file in openbmc/docs.

A related question is: Who are the machine maintainers? Off the top of
my head I feel the following machines machines match with people:

    meta-evb/meta-evb-raspberrypi                  Yi TZ Li <    shliyi at cn.ibm.com    >
    meta-evb/meta-evb-aspeed/meta-evb-ast2500      Joel Stanley <    joel at jms.id.au    >
    meta-x86/meta-mellanox/meta-msn                Mykola Kostenok <    c_mykolak at mellanox.com    >
    meta-x86/meta-quanta/meta-q71l                 Patrick Venture <    venture at google.com>    , Rick Altherr <    raltherr at google.com    >
    meta-openpower/meta-ingrasys/meta-zaius        Xo Wang <    xow at google.com    >
    meta-openpower/meta-ibm/meta-firestone         Lei YU <    mine260309 at gmail.com>    meta-openpower/meta-ibm/meta-romulus           Lei YU <    mine260309 at gmail.com>
meta-openpower/meta-ibm/meta-witherspoon       Brad Bishop <bradleyb at fuzziesquirrel.com>, Andrew Geissler <geissonator at gmail.com>

Less obvious are the following machines:

    meta-openpower/meta-ibm/meta-palmetto
    meta-openpower/meta-ibm/meta-garrison
    meta-openpower/meta-rackspace/meta-barreleye

Yet another related question is what do we want to do with machines
that don't have an obvious maintainer?

In the case of Palmetto I imagine we could find someone willing to step
up (/me ducks). Garrison I'm unsure about, and for Barreleye I've had
kernel patches on the list for several months with not a lot of
interest in them, which indicates to me that we could probably drop it.

As some background, Joel and I were recently discussing machine
maintainers with respect to the dev-4.13 kernel effort. The approach
Joel kicked off for dev-4.13 was to start from scratch against upstream
and distribute the forward-porting amongst owners of patches in dev-
4.10. That is, if you have patches in dev-4.10 and that are not in
upstream v4.13, you should rework and send them for us to apply to dev-
4.13.

To stress the point a bit, the dev-4.13 tree as it stands does not have
niceties such as `arch/arm/mach-aspeed/aspeed.c` or any of the machine-
specific devicetree files. The idea is that in addition to distributing
the workload, we only add back in what we need and try to avoid
carrying accumulated cruft across moves to new upstream releases.

Whilst the distributed approach eases the workload on Joel, it does
mean that we could miss things that are required for specific machines
(the board-file hacks are particularly worrisome). This is driving my
interest in identifying the maintainers. Having such a list of people
would, for instance, clarify who ought to be on the review list for
kernel bumps to openbmc/openbmc in Gerrit. In the case of dev-4.13 this
would help with the go/no-go decision.

So if you have thoughts on the above or want to put your hand up to
claim any of the machines in the limbo list above, please do speak up!

Cheers,

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20171013/1e98f1ab/attachment.sig>