reference platforms?

[Brad Bishop]

Hey Sai

Sorry it has taken me so long to respond.  I hope others will weigh in
with their ideas on this topic.

> On Apr 13, 2018, at 7:55 PM, Sai Dasari <sdasari at fb.com> wrote:
> 
> 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. 

Yep, I understand the goal.  I don’t have any great ideas off the top
of my head but I don’t think it should be too hard to come up with a
solution that meets both needs - a scalable development process _and_
a one-stop-shop for OCP platform builders (or others).

> 
>> 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}. 

I think this valid concern could mostly be mitigated by careful selection of
maintainers and how we structure content amongst repositories.  I will try
and elaborate on how I think it could work with some pictures in the near
future.

> 
>>> 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.
>> 
>>    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.