Re: Managing openbmc with subtree

[Dave Cobbley <david.j.cobbley@linux.intel.com>]

>> On Aug 7, 2018, at 1:16 PM, Dave Cobbley <david.j.cobbley@linux.intel.com> wrote:
>>
>> I do agree that we can find a scriptable solution to this, however, I feel using the OWNERS plugin provides a much easier workflow for all developers, i.e. nothing changes from their perspective.
> Hrm, while I agree that the OWNERS plugin preserves the existing workflow
> I’m not convinced that is the best path forward.
I suppose it does only give us one of the two goals, where as moving 
straight to subtrees fulfills all of the goals.
>
>>> This gives us the same process for all subtrees, whether or not they are
>>> openbmc hosted subtrees.  It also does not require people hacking on a
>>> subtree to clone OpenBMC when it doesn’t make sense for them to do that,
>>> such as someone just using the Aspeed BSP layer.
>
> I still have these concerns.
I understand your concerns and agree - Here is what I would propose for 
the subtree folder structure:

Splat * represents a subtree

Yocto & more:
import-layers/
     *meta-openembedded/
     *meta-virtualization/
     *poky/
     *meta-security/

BSP:
meta-openbmc-bsp/
    *meta-ibm/
    *meta-aspeed/
    *meta-nuvoton/
    *meta-raspberrypi/

MACHINES:
meta-openbmc-machines/
    meta-arm/
        *meta-qualcomm/
    meta-openpower/
        * meta-ibm/
        * meta-ingrasys/
        * meta-inventec/
        * meta-rackspace/
    meta-x86/
        *meta-intel/
        *meta-mellanox/
        *meta-portwell/
        *meta-quanta/

REFERENCE:
meta-phosphor/


-Dave