tracking master of upstream openbmc/openbmc subtrees

[Brad Bishop]

On Fri, Apr 05, 2019 at 06:40:53PM -0700, Patrick Venture wrote:
>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 Patrick.  Somehow I didn't realize that tiogapass had been turned
on :-(

>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