Reducing fragmentation in OpenBMC

[郁雷]

On Tue, May 19, 2020 at 8:50 PM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> On Tue, 2020-05-19 at 10:25 +0800, 郁雷 wrote:
> > On Tue, May 19, 2020 at 8:53 AM Andrew Geissler <
> > geissonator at gmail.com> wrote:
> >
> > > 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?
> > >
> >
> > This usually involves the repo CI.
> > If we could implement "Cross-repo dependencies", making the Jenkins
> > job able to pick the "dependent" revision of phosphor-dbus-interfaces
> > (or sdbusplus, or else), and build a docker container with the
> > dependencies to run the repo CI, the issue could be resolved.
>
> This would be a nice feature to have in our CI when cross repo
> dependencies come up.  But I don't think  having that would give us
> free license to add cross repo dependencies everywhere though - I would
> like to see us come up with a system that avoids the need for cross-
> repo dependencies in the first place.

As Andrew indicates, phosphor-dbus-interfaces is the major cross repo
dependency already.

-- 
BRs,
Lei YU