Managing openbmc with subtree

[Brad Bishop]

> On Aug 8, 2018, at 6:14 PM, Dave Cobbley <david.j.cobbley at linux.intel.com> wrote:
> 
> 
>>> On Aug 7, 2018, at 1:16 PM, Dave Cobbley <david.j.cobbley at 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

Is this an agreement to my proposed workflow?

For reference the proposal was distro hackers could have an openbmc/openbmc repo
with multiple remotes, one for the distro and one for each subtree and then:

>>>> $ git checkout -b phosphor-master meta-phosphor-gerrit/master
>>>> $ git cherry-pick —-strategy=subtree -Xsubtree=meta-phosphor <openbmc/openbmc-sha>
>>>> $ git push meta-phosphor-gerrit HEAD:refs/for/master
> 
> - 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/

Would it make sense to put meta-* directly in the root, along with all our other
subtrees?  I don’t see the point in calling them out as upstream trees - I’d like
to see some or all of our project meta trees become hosted elsewhere someday,
much in the same way as meta-virt for example.

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

lgtm

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

I’d like to get away from this and just put the company subtrees at the root.
That way meta-xyzcorp could support both an x86 and an arm server.

> 
> REFERENCE:
> meta-phosphor/

I’d suggest the arch metas here, at the root.  Honestly I’d like to get to a point
where all the arch layers are just merged into meta-phosphor and we can say
meta-phosphor supports x86, power, and arm servers (along with TORSes).  But we can
save that for another day.

> 
> 
> -Dave

So to net these all out:

*poky/

*meta-openembedded/
*meta-virtualization/
*meta-security/
*meta-arm/
*meta-openpower/
*meta-x86/
*meta-phosphor/

*meta-aspeed/
*meta-nuvoton/
*meta-raspberrypi/

*meta-intel/
*meta-mellanox/
*meta-portwell/
*meta-quanta/
*meta-ibm/
*meta-ingrasys/
*meta-inventec/
*meta-rackspace/
*meta-qualcomm/