Thud branches required in certain repos?

[Andrew Geissler]

On Mon, Jan 21, 2019 at 4:45 PM Joseph Reynolds <jrey at 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
>