Machine-scope maintainers for OpenBMC

[Lei YU]

Hi Andrew, Brad,

I would like to bring a question about how do we welcome system
vendors' systems.

Background: in gerrit we already have some system vendors' machines
under review:
* meta-inventec/meta-lanyang: https://gerrit.openbmc-project.xyz/#/c/3888/
* meta-yadro/meta-vesnin: https://gerrit.openbmc-project.xyz/#/c/6429/

They both contain a "large" commit that introduce a machine.

I know we have suggestions to split the commit into separated smaller
ones, but this
seems a bit hard:
* The work is based (referenced) on a similar machine, e.g palmetto or
zaius, which
   means the base code (meta-xxx) is already big;
* The change is submitted as a "squashed" one after it's built and
tested, which means
   not each "internal" commit can be built successfully.

In such case, how do we handle this case? Is it possible to accept a
large squashed commit
if and *only* if the change is to introduce a new meta-machine?

Thanks!


On Fri, Oct 13, 2017 at 12:16 PM, Andrew Jeffery <andrew at aj.id.au> wrote:
> 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