tracking master of upstream openbmc/openbmc subtrees

[Patrick Venture]

On Fri, Apr 5, 2019 at 11:04 AM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> 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

Found some other layers that needed updating.  One of which because
it's part of the CI.  Sent patches for review with the same topic.
Thanks

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