2 patch dependency

[Brad Bishop]

> On Nov 22, 2019, at 12:36 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> Thanks Brad.
> 
> On Fri, Nov 22, 2019 at 10:44:16AM -0500, Brad Bishop wrote:
> 
>> A brief history lesson for any that aren’t aware - the original workflow was patches were submitted to openbmc/openbmc for subtrees where we are as far upstream as you can get.  We moved from that to the workflow we have today because of a desire of mine and others for de-centralized ownership of metadata.
>> 
>> To enable that I proposed the same process that the Yocto project uses to aggregate the various sub-projects into the poky distribution.  This is how we wound up with the workflow we have today.  In hindsight this was a mistake.
> 
> Can you elaborate briefly on the issues you've had with it?  

Well for one, the issue that started this thread - coreqs.  they are harder than they need to be with the current workflow.

Also the two step CI verification that comes with it is not good - it halves our already limited resources.  Although now that I think about it I don’t recall why we felt this was necessary…

Finally it is just awkward and lame to clone openbmc/openbmc, hack on it, and then have mess around with adding additional remotes and doing subtree cherry-picks, etc… to submit a patch.

> It seems 
> like many metas with subtree, many metas with repo, or mono-repo all have
> advantages and disadvantages and are just different ways people have
> attempted to skin the same animal.  

Could we not have all of them at the same time?

> 
>> The proposed change would simply be that we revert back to the old workflow, which was much simpler, and use the Gerrit plugin to implement the de-centralized ownership requirement.  There have been and will be a couple enhancements since we last used that workflow though:
>> 
>> 1 - I track poky/meta-openembedded head. Last time we tracked the latest released version.  This has worked fine; I am not aware of a single instance of upstream breaking us or causing any instability.
> 
> Is there any interest in supporting multiple Yocto releases at a time?

I don’t have a need for this.

> This would be one advantage of using repo.  

The word advantage implies repo would replace something else.  What do you want it to replace?

> You can have different
> manifest files for the different Yocto branches.  That way we can keep
> pointing to an LTS Yocto but with newer OpenBMC code (for people who
> might desire that when putting OpenBMC into production).

makes sense.

> 
> 
>> As far as repo goes - in my mind that is something completely separate.  If anyone wants to maintain a repo manifest somewhere I don’t have a problem with that.  It doesn’t have to have anything to do with the patch submission workflow.
> 
> I'm not really following how any of the options have a big impact on patch
> submission workflow.  

agreed.  In fact…is there anything you need from the community to start maintaining a repo manifest today?  I don’t think there is, is there?  Maybe a git repo to put it in?

> Most developers just contribute to whatever
> repository is considered the "master" of where they're making changes.
> If that is a subtree or a monorepo, does it really have much bearing?
> (I guess it has impact in the cases where we need to span what are
> currently subtrees?)
> 
> Having a repo manifest simplifies two things:
>    1. Implementation of cross-repo CI (and the topic-based testing I
>       mentioned) because there is a clear assembling of all the git
>       repositories that might be impacted by a topic.
> 
>    2. A mechanism for developers to "get all the code".  I've heard
>       complaints of developers having to manually assemble a collection
>       of git-clones for all the different sub-projects they tend to
>       work on.  A maintained manifest of all the openbmc/* repositories
>       would alleviate this.

I think you are driving at a couple things:

1 - patch submitters should continue to submit patches to meta-*, poky, meta-openembedded, etc.
2 - you start maintaining a repo manifest.
3 - everyone will abandon the current monorepo composed of subtrees.

Do I have it right?

What I’m asking for instead is:

1 - patch submitters submit patches to openbmc/openbmc (unless there is an upstream community)
2 - patches (immediately) find their way into meta-* via automation
3 - you start maintaining a repo manifest
4 - I continue to maintain a monorepo composed of subtrees (the ones with upstream communities) & directly submitted patches

thx - brad