reference platforms?

[Brad Bishop]

I think in the not-too-distant-future we are going to need a concept of reference
platforms.

openbmc/openbmc is essentially the same thing as Poky.  A super-repo
of other upstream repos (bitbake, oe-core, etc…).  Our upstream repos
just happen to be different things like poky, meta-virtualization, meta-phosphor,
meta-aspeed, etc.

But the similarity ends when you look at the platforms supported.  Poky
has a set of reference platforms.  Any other platforms or distros using
Poky are not the Yocto projects concern - they are completely maintained
by the project that uses Poky (like us!).

Thus far we have not really put any filter on what machines you get
when you clone openbmc/openbmc.  I think that needs to change to a model
like the one the Yocto project uses.  The clear benefits I see to that
are:

- It addresses a scaling problem in the openbmc/openbmc repository.  We
are on track to repeat the mistakes of the openembedded project that led
to the formation of Poky in the first place.  That is, we cannot add new
platform and BSP layers indefinitely.  At some point it will become
unmanageable.  Part of me wonders if we are already there.

- Testing.  Obviously a developer cannot test a patch on 100 platforms or
10 different SOCs.  So what is the developer expected to test on?  A reference
platform.  Then who tests the other systems?  The maintainers of those
systems.  Adopting the same mode of thinking as Poky makes this distinction
clear.

So what does everyone think of the idea of reference platforms?  Can
they help the OpenBMC project?

So the obvious next question is…what are the metrics for defining reference
platforms?  I predict finding the answer to that will be a challenge :-).

Go ahead and throw crazy ideas out there.  Pay money to the project?  Most
days without a compile failure?  There are about a million things we could
do here - but what does everyone find fair?

thx - brad