Thud branches required in certain repos?

Joseph Reynolds jrey at linux.vnet.ibm.com
Tue Jan 22 09:51:31 AEDT 2019


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



More information about the openbmc mailing list