2 patch dependency

[Patrick Williams]

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?  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.  (There is also submodule, but
*yuck*...).

> 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?
This would be one advantage of using repo.  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).

> 
> 2 - I would automate the subtree pushes. Last time this was done manually (and thus the subtrees were often stale).

:+1:

> 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.  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.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191122/096fca72/attachment.sig>