tracking master of upstream openbmc/openbmc subtrees

[Brad Bishop]

On Mon, Feb 04, 2019 at 04:07:35PM -0500, Brad Bishop wrote:
>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

Just a quick update - Thanks to some help and motivation from William
and others, this will (probably) happen/begin today.  A couple things to
note.

1 - If you maintain a layer, you'll need to update your layer
compatibility like this:

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

Although you won't need to keep thud compatibility like that commit
does.

2 - I decided to remove rsyslog inclusion by default
https://gerrit.openbmc-project.xyz/20214 because of
https://github.com/openbmc/phosphor-logging/issues/19.  This allows us
to move our upstream subtrees forward and debug
openbmc/phosphor-logging#19 in parallel - I expect there aren't too many
users of rsyslog anyway.  If I'm wrong about that please let me know but
I also expect that issue to get fixed up in the next couple weeks
regardless.

Please let me know if I've caused anyone pain with any of this.

thx - brad