What does it take for OpenBMC to merge code

[Chris Austen]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170822/5ea465c3/attachment.html>