Re: Reducing fragmentation in OpenBMC

[Andrew Geissler <geissonator@gmail.com>]

> On May 15, 2020, at 4:03 AM, Jeremy Kerr <jk@ozlabs.org> wrote:
> 
> 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).

I know phosphor-dbus-interfaces has always been a bit onerous. I do feel like
we get some good stuff in the reviews though. It also ensures we have
documentation  of our interfaces. The cross-repo dependencies we
get are a bit frustrating (i.e. need to get interface merged and bubbled into
openbmc before you can implement). There’s also no versioning concept so
if an interface needs to be changed, it’s a huge pain. Ideas on how we could
make this easier but keep the benefits? Or people that don’t use it and just
define their own interfaces, any improvements we could make to get
you to use it?

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

This is definitely a big one. I’m not sure the solution though. There’s a
divergence between platforms. I know there’s some effort to to converge a bit
(entity manager usage) but  we seem to still be going through that phase where
we have multiple implementations of things and we’ve just got to let them work
themselves out. That can be confusing to new people coming in. A lack of an
affordable reference platform we can point people to is something that comes up
often in the community.

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

Good topics and thanks for starting the discussion Jeremy!

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