What does it take for OpenBMC to merge code

[Andrew Jeffery]

Hi Chris,

On Tue, 2017-08-22 at 10:27 -0500, Chris Austen 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?

I feel that the question is broader than that:

	What defines OpenBMC as an OS distribution?

The properties that we cook up in answer to that would provide guidance about
what designs and code would be considered acceptable.

> If I add my own meta layer will it be accepted? What if I
> wrote a device driver that satisfies my own hardware needs?

Nit-picking at the kernel bit, I'd hope that the author sends the patches
upstream!

> What if I wrote a dbus telemetry monitor with the capability to download
> results in python? The https://github.com/openbmc/docs/blob/master/co
> ntributing.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?

"Collection of random software" is a bit loose, but I'd like to steer clear of
requiring adherence to a structured framework; I feel like that might
inductively lock us into decisions we make (or have made) now.

My preference is that the project provides a bag of tools and a build system
that someone can take to construct a BMC distribution, mixing and matching bits
as they go.  This may require little or lots of effort on their part, but how
much effort someone spends isn't our decision. Composability over monolithic
frameworks.

> 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 find it hard to address this point without getting distracted by how we
define conformant, but you're probably right. Whatever is out-of-tree is
unsupported from the perspective of the project.

However I think that we need to be flexible in what the project accepts
(conformance). Particularly, if someone has a relevant contribution that they
are willing to maintain then we enable them to do so. What we need to enable
*that* is to develop a model where code ownership can be sensibly distributed
through the community.

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

Would it in general/the future? It does for what we have currently - D-Bus is
fundamental to the reference phosphor userspace. However this suggests to me
that you've written the post with pre-conceived notions of what should define
OpenBMC going forward, but haven't explicitly called out what they are.
Outlining them will help everyone to understand your position.

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

I'd say even for established models. Just because something's established
doesn't mean it can't be improved. It's less likely, but that shouldn't stop
people making suggestions.

Regardless, I think communication of ideas, desires, designs and implementation
strategies on the mailing list is essential.

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

I think discussing a staging area would be more useful when we have a better
understanding of what we're building as a community. We should probably iron
that out before splitting hairs about quality issues that might relegate
contributions to a staging area.

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

Absolutely agree on clear messaging: Managing expectations is important, and
I feel minimising disappointment in a community that is still early in its
growth phase is essential.

Cheers,

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170823/9e68a5ec/attachment-0001.sig>