2 patch dependency

[Andrew Geissler]

> On Nov 19, 2019, at 10:54 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> On Tue, Nov 19, 2019 at 09:45:34AM -0600, Andrew Geissler wrote:
>> 
>> I know in general we really try to encourage people to not cause
>> co-req issues across repositories. Making this easier for people
>> may cause more of it to happen.
> 
> I understand and agree.  I don't know how often this kind of breaking
> behavior has happened, like these IPMI related changes, it was just
> coincidentally at the top of my email queue as I've started digging
> through.
> 
>> Also, I believe we’re going back to just having everything in
>> openbmc/openbmc so that should alleviate a lot of our meta-*
>> co-req issues since they can all go in together again. Brad was
>> working on getting the gerrit plugin running that allows people
>> to maintain sub-directories in a repository. This will allow multiple
>> maintainers of openbmc/openbmc for their specific areas.
> 
> Ooh.  Was this talked about on the mailing list somewhere?  I've gone
> back through at least August and haven't come across it.  Was there
> an exploration of moving to `repo` instead?

May have only been IRC, I’ll let Brad handle this one. I just know
that my vote is to get away from subtree. It made the dev process
more difficult/complex and it doubled the required capacity of our CI
infrastructure.

> 
>> So to answer your question, I’m not sure. I think it could still
>> be useful to have between code repos and openbmc/openbmc
>> at times but I’d rather people just do the extra work to avoid
>> dependencies all together.
> 
> Another "first step" might be to get a Jenkins job for code repositories
> that builds the full openbmc/openbmc stack with the code change, so that
> we can identify breaking changes like this before they are merged.

Yes, this is definitely on the list. We run redfish validation on all
images and it continues to find good regressions but that’s always
after the code has been merged into bmcweb and pushed up to
meta-phosphor. We would like to at least enable this feature
(full flash image build) for bmcweb so we can get this
coverage earlier. Once we get rid of the meta-* layer CI
we should have enough compute power to do this.

> AFAIK, the code repo Jenkins jobs are still independent from the Yocto
> recipes, correct?

Yes, still independent. So we’d run that normal code repo CI
and if that passed, do a devtool or recipe update to build
the change into a bitbake image for further CI.

> 
> -- 
> Patrick Williams