What does it take for OpenBMC to merge code

[Joel Stanley]

Hi Chris,

On Wed, Aug 23, 2017 at 12:57 AM, Chris Austen <austenc at us.ibm.com> wrote:
> For a some time now a question keeps popping up. I ask others for an answer
> and get I different responses. It's time I bring this to the mailing list
> for further discussion... what will the OpenBMC project merge? If I add my
> own meta layer will it be accepted? What if I wrote a device driver that
> satisfies my own hardware needs? What if I wrote a dbus telemetry monitor
> with the capability to download results in python? The
> https://github.com/openbmc/docs/blob/master/contributing.md file goes in to
> some detail but is pretty blank on the practice of what kind of code will go
> in.
>
> So, what should the policy be?
>
> Should the OpenBMC project be a collection of random software or a
> structured framework or somewhere in between? Some pieces may need to be
> hosted independently... hosting non-comformant parts implies a level of
> support and maintenance which is something we should not be doing.

I'd like to see an inclusive policy to start with. We've seen several
approaches to an open source BMC stack over the past year, with
Facebook's initial Yocto-based OpenBMC, the OpenWRT based design,
IBM's 'phosphor' yocto layer, and Mellanox's OpenIPMI based variant.
They are all interesting in their own way, and bring their own
strengths to the project.

Having this list be a central place to collaborate would be my initial
goal. From there we can refine the direction for the project, and
introduce some guidelines that direct future development. Things like
the use of D-Bus, and Redfish REST APIs, are areas that we appear to
have common ground.

Cheers,

Joel

>
> What about code with existing modeled concepts. IPC is done via dbus, LEDs
> and Sensors too have established meta-phosphor implementations. Changing
> those idea would break down the fundamentals of what OpenBMC is. For models
> that have not been established yet perhaps the developer should be active on
> the mailing list describing the issue so that we can provide guidance?
>
> Is there a place for staging? The Linux kernel uses them for less stable
> code. Using a staging area does at least two things...
> 1) Recognizes anyone coming to the table brings their own companies history
> and business requirements
> 2) Allows developers to share ideas that could build in to an approved model
>
>
> There are groups that want to get involved and are at various stages of
> OpenBMC understanding. We owe it to them to be very upfront about what the
> community will and will not accept.
>
> Thoughts?
>
> Chris Austen
>