tracking master of upstream openbmc/openbmc subtrees

tracking master of upstream openbmc/openbmc subtrees

[Brad Bishop]

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

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

Re: tracking master of upstream openbmc/openbmc subtrees

[Patrick Venture]

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

Re: 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@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

Re: tracking master of upstream openbmc/openbmc subtrees

[Vijay Khemka]

On 4/6/19, 6:09 AM, "openbmc on behalf of Brad Bishop" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of bradleyb@fuzziesquirrel.com> wrote:

    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@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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_17387&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=EuMZ_W1n48uLmY-o2Cy_IXfkr_-3ak_OD257eGLLPJI&s=-HrQIFk2XgO0N_HLArIhx7wxxN0xJVKQ7rSJyaGqmdw&e=
    >> >
    >> >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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_20150&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=EuMZ_W1n48uLmY-o2Cy_IXfkr_-3ak_OD257eGLLPJI&s=BLwDd0Vlmz39jm1Gtc7Qh4KnVH9vN4g88DnKb8dD-RA&e=
    >
    >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 :-(
Tioagapass was turned on in CI 4 months back. I will maintain and support tiogapass tree if any update required here.
    
    >Thanks
    >
    >>
    >> Although you won't need to keep thud compatibility like that commit
    >> does.
    >>
    >> 2 - I decided to remove rsyslog inclusion by default
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_20214&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=EuMZ_W1n48uLmY-o2Cy_IXfkr_-3ak_OD257eGLLPJI&s=NtU7rv5nWjhBT6tRnAXnzbveD2eS79lmmvHHTzQTNRI&e= 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