reference platforms?

[Sai Dasari]

    What does that mean exactly?  Something like you can do this and it works:
      git clone github.com/openbmc/openbmc
      cd openbmc
      git clone github.com/<awesome-company>/my-obmc-machine-layer
      bitbake obmc-phosphor-image
    
    And if you ask the question in this way, I’m not sure what the answer is.
    How do you find all the layers that work with Poky?  Can you elaborate on
    why the answer might be important to someone?  It is a fair question but I
    can tell you that it isn't one that IBM for example needs answered in order
    for the project meet its product development needs.
Your proposed changes are good from scaling the development. My original question was from the end-user point of view who acquires bunch of OCP machines and tries to find a way to build OpenBMC for those machines. I was wondering if we can point those end-users to one unified repo @ "github.com/openbmc" and allow them to build OpenBMC binary for that platform. The other option would be for them to let them figure out the repo for that machine e.g. "github.com/<awesome-company>". I think any of these methods will work in practice. 
    
    Put another way, we _could_ build the answer to the question into the
    core of the project, but why (and at what cost to the project’s ability
    to scale)?  Someone could also just host a list somewhere, or maybe a
    layer-index like OE has?
    
    > Does each openbmc adopter encouraged to maintains independent github repo with recipes needed to bring in the openbmc code and build for their supported machines? 
    
    I think so.  The specifics of what the adopter does/maintains are up to
    the adopter.  What are some pros/cons of a model like that?  This is what
    most everyone is doing already.  They fork some part of the project (or
    all of it), build on it (mostly in a machine layer?  hopefully?)  and then
    maybe/maybe not contribute something of what they did back to the upstream
    project.  It is my guess that this is the usual way in which product
    development teams use FLOSS.
I am sure FLOSS allows forks, but for the benefit of community, it would be good to encourage contribution to the upstream openbmc repo. While it helps to scale to separate machine layer repo outside of upstream, I have concern that the adopter's focus would shift away from upstream to that external repo. This might have side-effect of duplicate work in independent repos (might have good intention of upstreaming later), as opposed to ideal work flow (in my mind) of {'upstream-first'-> cherry pick to external repo}. 
    
    > One (crazy) idea would be to come up with a minimum acceptance test suite (which can be automated) that validates all the core features and use this for accepting new platforms as reference platforms from community.
    
    This is the opposite of crazy Sai :-)
    
    I like it, with a tweak/clarification.  Remember that one of the points of
    a reference platform is to enable regression testing for the project.  So
    when someone changes the common code in phosphor-hwmon for instance, we need
    a way to test that it isn’t going to break as many OpenBMC users as we can,
    without needing to test all their platforms for them.
    
    So my clarification is that the acceptance test would not measure how well
    a machine meets end-user requirements, but rather how well a machine makes
    use of the project’s common code.  Maybe a metric measured by the test could
    be something like least number of deviations from the defaults?
Looks good metric to me for various application level service/daemons. Still not sure how the code changes specific to hardware can be regression tested e.g. KCS vs. BT, IPMB, NC-SI etc.