2 patch dependency

[Andrew Geissler]

> On Nov 18, 2019, at 6:35 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> On Tue, Nov 05, 2019 at 09:27:21AM -0500, Brad Bishop wrote:
>> 
>> 
>>> On Nov 1, 2019, at 3:18 PM, Vijay Khemka <vijaykhemka at fb.com> wrote:
>>> 
>>> We have issue of merging 2 commit which are dependent to each other. I am not sure how are we going address this. 
>> 
>> I’m working on this today:
>> 
>> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/26910
> 
> Do we have any sort of topic-based multi-repo testing?  If not, is there
> any interest in developing it?

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.

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.

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.

> 
> I implemented this on another project:
>   * Whenever Jenkins was triggered by Gerrit, it looked at the
>     GERRIT_TOPIC variable to determine if the change belonged to a
>     topic.
>   * If the commit was in a topic, Jenkins queried Gerrit for all open
>     changes that belonged to the same topic.  Using `repo`, Jenkins
>     would extract all of these changes into a working directory and
>     `bitbake` to kick off a build.
> 
> This was useful both commits that spanned metas and for commits that
> involved both code and recipe changes.  This was really useful for
> changes that added a new dependency so you didn't have to add a
> free-standing recipe update with a "trust me, the code is coming that is
> going to need this dependency" kind of comment.
> 
> I know we're not using `repo` right now and so there is some work
> involved in making this span the OpenBMC code repositories, but a simple
> first step would be to get this working across the meta subtrees.  Would
> this help changes like Vijay's so we don't need to involve a cross-meta
> maintainer?
> 
> -- 
> Patrick Williams