Reducing fragmentation in OpenBMC

郁雷 at
Tue May 19 12:25:28 AEST 2020

On Tue, May 19, 2020 at 8:53 AM Andrew Geissler <geissonator at> 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.
For example:
* A change in phosphor-dbus-interfaces is submitted to gerrit with
revision `abcd` and Change-Id `wxyz`, which is not yet merged;
* A change in repo is submitted to gerrit, with commit message
containing `Depends-On: wxyz`

The Jenkins repo CI job needs to figure out that this commit depends
on `wxyz`, which is phosphor-dbus-interfaces.
Then it needs to build the container with `abcd` revision of
phosphor-dbus-interfaces, and run the repo CI.

It requires non-trivial changes to the Jenkins job though.

Lei YU

More information about the openbmc mailing list