Reducing fragmentation in OpenBMC

* Reducing fragmentation in OpenBMC
@ 2020-05-15  9:03 Jeremy Kerr
  2020-05-15 10:45 ` Jeremy Kerr
  2020-05-19  0:53 ` Andrew Geissler
  0 siblings, 2 replies; 10+ messages in thread
From: Jeremy Kerr @ 2020-05-15  9:03 UTC (permalink / raw)
  To: openbmc

[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]

Hi OpenBMCers,

I've been working on some different areas of OpenBMC recently, and have
noticed that there seems to be increasing fragmentation between various
platform and infrastructure code.

One of the main impacts I've seen as a consequence is that it's
becoming incredibly difficult for new adopters and contributors to do a
platform port.

I definitely understand that contributing companies have their own
product timelines and priorities, which doesn't always correlate with
OpenBMC development directions. We need to allow that for the project
as a whole to be viable. But I still think there's scope to both
improve the coherence of the OpenBMC work, while also allowing variance
where justified, in a way that makes sense.

To pick a couple of examples and consequences:

 - there are a lot of out-of-tree patches around. While this isn't
necessarily a problem in its own right, some of these are fundamental
to make the upstream platforms work. For anyone adopting those
platforms as a reference, it means that they have a non-functional
platform, or have to use the non-upstream repos.

 - there's increasing amounts of code that require or implement non-
standard behaviour; For example, dbus-sensors exposes and consumes dbus
interfaces that are not described by phosphor-dbus-interfaces. This
means that the divergence is then needed in other projects too. If
those standards don't suit actual requirements, then we should look at
updating them.

Just to be 100% clear though, I am definitely not singling-out the
meta-intel platform support; it's just what I've been experimenting
with recently. Intel have done great upstream work on OpenBMC, and
these issues are only apparent because of the work already done. It
just feels like we're 90% there, and the rest would make the world of
difference for new users.

So, a few things that I think may help the situation:

 - Adherence to standards. Being a little more strict about what
comprises an OpenBMC implementation will go a long way to prevent
future incompatibilities, and means that all of our interface
implementations automatically document their expected behaviour
(because that's in the standard).

 - Identification of a set of reference platforms. If we can point
adopters to a platform that provides a recommended (and somewhat
"supported") way of doing things, that would prevent a lot of confusion
around different implementations, and how to best work with the options
available

 - Documentation of interactions between components. There's some great
documentation on how our components work, but not a whole lot on how
they fit together. Without this, it means a lot of jumping around
between repos, trying to find the "other side" of each interface.

 - Keep pushing on upstream. Sometimes this can delay things, but I
really think that's almost always false economy; the out-of-tree
patches will have to be addressed at some point, and that job just gets
more involved as time passes. Even engaging other community members to
help out would be great.

Finally, I don't mean this to sound like a bunch of complaints - I'm
keen to put in a bunch of time to address things. I'd just like to
start some discussion on how best to do that, before I do so.

So - any thoughts on how we can improve this? Comments / disagreements
/ questions always welcome.

Cheers,

Jeremy

[-- Attachment #2: Type: text/html, Size: 8677 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread