tracking master of upstream openbmc/openbmc subtrees

Brad Bishop bradleyb at fuzziesquirrel.com
Tue Feb 5 08:07:35 AEDT 2019


Hi everyone

Just a heads up - in the very near future I'd like to start tracking the
master branch of our upstream subtrees - poky, meta-openembedded,
meta-security, meta-raspberrypi and meta-xilinx:

https://gerrit.openbmc-project.xyz/17387

This removes the need to backport fixes from these projects and thinking
generally, might increase the collaboration between the OpenBMC
community and the upstream communities on which our project so
fundamentally depends.

In practice this will really just look like:

https://github.com/openbmc/openbmc/commit/cdf4859f9e74293090d79c02949fa6a694bdb1d5

but the commits will have more content and happen more frequently.

There are a couple caveats - one, upstream may break more frequently
than it does on the stable branches, and two, given the location of
these projects in the stack (low), more frequent rebases will result in
some impact to the development workflow (more time building because a
patch was applied to gcc, etc).

To mitigate number one, I will submit rebases as patches to gerrit where
our CI tests can run.  If they find any problems, I won't merge the
rebase until a resolution is found.  Additionally if you find any
problems via some other channel than our CI, let me know and again I
won't apply the rebase until a resolution can be found.  Put another way
I don't intend to rebase onto upstreams with known problems for us.

To mitigate number two, I was thinking I'd just submit rebases weekly.

Questions/concerns?

thx - brad


More information about the openbmc mailing list