Thud branches required in certain repos?

Thud branches required in certain repos?

[Andrew Geissler]

Recently we created a Thud branch (i.e. 2.6). Currently we've just branched
the openbmc/meta-* and openbmc/openbmc layers.

Pre repository CI (i.e. https://openpower.xyz/job/openbmc-repository-ci/) had
its scripts updated to support the new branch. Basically if a change comes in
from a branch, it will attempt to find and use that same branch from all of
the dependent repositories. If it can't find the branch, then it will just
use master from that build.

Dependent repositories are repositories that most repositories depend on and
are always built as a part of the per repository CI process:

  phosphor-objmgr
  sdbusplus
  sdeventplus
  gpioplus
  phosphor-logging
  phosphor-dbus-interfaces
  openpower-dbus-interfaces

In general, just using master from these dependent repositories will work. We
only run into issues if some sort of API or data type change occurs in master
that is not compatible with the branch.

To avoid weird errors in the future though, I'd like for the maintainers of the
above repos to create the corresponding branch in each of the above repos
whenever a new branch is created for the openbmc project.

Adding a branch is easy, just go to your project in gerrit and use the
"Create Branch" option. Be sure to put the "Initial Revision" commit at whatever
we were at when the Thud branch occurred and call it "thud".

Other ideas or thoughts?

Andrew

Re: Thud branches required in certain repos?

[Joseph Reynolds]

On 2019-01-21 11:23, Andrew Geissler wrote:
> Recently we created a Thud branch (i.e. 2.6). Currently we've just 
> branched
> the openbmc/meta-* and openbmc/openbmc layers.
> 
> Pre repository CI (i.e. 
> https://openpower.xyz/job/openbmc-repository-ci/) had
> its scripts updated to support the new branch. Basically if a change 
> comes in
> from a branch, it will attempt to find and use that same branch from 
> all of
> the dependent repositories. If it can't find the branch, then it will 
> just
> use master from that build.
> 
> Dependent repositories are repositories that most repositories depend 
> on and
> are always built as a part of the per repository CI process:
> 
>   phosphor-objmgr
>   sdbusplus
>   sdeventplus
>   gpioplus
>   phosphor-logging
>   phosphor-dbus-interfaces
>   openpower-dbus-interfaces
> 
> In general, just using master from these dependent repositories will 
> work. We
> only run into issues if some sort of API or data type change occurs in 
> master
> that is not compatible with the branch.
> 
> To avoid weird errors in the future though, I'd like for the 
> maintainers of the
> above repos to create the corresponding branch in each of the above 
> repos
> whenever a new branch is created for the openbmc project.
> 
> Adding a branch is easy, just go to your project in gerrit and use the
> "Create Branch" option. Be sure to put the "Initial Revision" commit at 
> whatever
> we were at when the Thud branch occurred and call it "thud".
> 
> Other ideas or thoughts?

Let's walk through a scenario.  Suppose we need to fix a bad problem in 
the OpenBMC 2.6 release in the sdbusplus repo.

The way I understand it, a pre-requisite step would be to fix the 
problem in the master branch of sdbusplus and then bump the master 
branch of openbmc to use the new version of sdbusplus.

The next step (given the proposal above) is to commit the fix to the 
head of (repo=sdbusplus, branch=thud) and then create a new commit in 
(repo=openbmc, branch=thud) which bumps the new version of sdbusplus.  
When this is done, someone who checks out (repo=openbmc, branch=thud) 
will pick up the fixes in (repo=sdbusplus, branch=thud).  Correct?

I can foresee a problem if the (repo=openbmc, branch=thud) update points 
to a sdbusplus version that is past the 2.6 version but not in 
branch=thud.  For example, if it pointed to the branch=master version of 
the fix.  That would pick up not only the sdbusplus fix, but also all 
development work that happened after the 2.6 release.  Is that the 
"weird" error you refer to?

To prevent this problem: when making bumps in (repo=openbmc, 
branch=thud), reviewers must ensure both (a) the fix was correctly 
copied (or cherry picked) from branch=master into branch=thud, but also 
that the version bump (in repo=openbmc, branch=thud) points to the 
branch=thud version (srcrev) and NOT to the branch=master version.

Anything else?

- Joseph

> Andrew

Re: Thud branches required in certain repos?

[Andrew Geissler]

On Mon, Jan 21, 2019 at 4:45 PM Joseph Reynolds <jrey@linux.vnet.ibm.com> wrote:
>
> On 2019-01-21 11:23, Andrew Geissler wrote:
> > Recently we created a Thud branch (i.e. 2.6). Currently we've just
> > branched
> > the openbmc/meta-* and openbmc/openbmc layers.
> >
> > Pre repository CI (i.e.
> > https://openpower.xyz/job/openbmc-repository-ci/) had
> > its scripts updated to support the new branch. Basically if a change
> > comes in
> > from a branch, it will attempt to find and use that same branch from
> > all of
> > the dependent repositories. If it can't find the branch, then it will
> > just
> > use master from that build.
> >
> > Dependent repositories are repositories that most repositories depend
> > on and
> > are always built as a part of the per repository CI process:
> >
> >   phosphor-objmgr
> >   sdbusplus
> >   sdeventplus
> >   gpioplus
> >   phosphor-logging
> >   phosphor-dbus-interfaces
> >   openpower-dbus-interfaces
> >
> > In general, just using master from these dependent repositories will
> > work. We
> > only run into issues if some sort of API or data type change occurs in
> > master
> > that is not compatible with the branch.
> >
> > To avoid weird errors in the future though, I'd like for the
> > maintainers of the
> > above repos to create the corresponding branch in each of the above
> > repos
> > whenever a new branch is created for the openbmc project.
> >
> > Adding a branch is easy, just go to your project in gerrit and use the
> > "Create Branch" option. Be sure to put the "Initial Revision" commit at
> > whatever
> > we were at when the Thud branch occurred and call it "thud".
> >
> > Other ideas or thoughts?
>
> Let's walk through a scenario.  Suppose we need to fix a bad problem in
> the OpenBMC 2.6 release in the sdbusplus repo.
>
> The way I understand it, a pre-requisite step would be to fix the
> problem in the master branch of sdbusplus and then bump the master
> branch of openbmc to use the new version of sdbusplus.
>
> The next step (given the proposal above) is to commit the fix to the
> head of (repo=sdbusplus, branch=thud) and then create a new commit in
> (repo=openbmc, branch=thud) which bumps the new version of sdbusplus.
> When this is done, someone who checks out (repo=openbmc, branch=thud)
> will pick up the fixes in (repo=sdbusplus, branch=thud).  Correct?
>
> I can foresee a problem if the (repo=openbmc, branch=thud) update points
> to a sdbusplus version that is past the 2.6 version but not in
> branch=thud.  For example, if it pointed to the branch=master version of
> the fix.  That would pick up not only the sdbusplus fix, but also all
> development work that happened after the 2.6 release.  Is that the
> "weird" error you refer to?

My error is outside of the openbmc repo discussion, although what you
point out could def be an issue if we don't ensure the proper pointers
to the individual repositories and their branches.

Here's the problem I'm looking at, going along with your example:

The fix is put into (repo=sdbusplus, branch=thud)
Currently, the CI job would use (repo=sdeventplus,gpioplus,..., branch=master)
to build all of the dependencies for sdbusplus. Lets say there's an interface
change in phosphor-dbus-interfaces in master, that (repo=sdbusplus, branch=thud)
does not support. The compile will fail. The solution is that all
dependent library
repositories need to have a thud branch that CI can build against.

>
> To prevent this problem: when making bumps in (repo=openbmc,
> branch=thud), reviewers must ensure both (a) the fix was correctly
> copied (or cherry picked) from branch=master into branch=thud, but also
> that the version bump (in repo=openbmc, branch=thud) points to the
> branch=thud version (srcrev) and NOT to the branch=master version.
>
> Anything else?
>
> - Joseph
>
> > Andrew
>