Managing openbmc with subtree

[Dave Cobbley]

On 08/09/2018 01:16 PM, Brad Bishop wrote:
>> 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?
I am running through the workflows locally to ensure the paradigm works 
as planned.
I have verified that the commit and subtree branch/push works - still 
working through how a dev would go work on something else, and then jump 
back into the feature to update the commit.
>
> 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.
>
Sure I believe that is fine. I like to put things in boxes so that habit 
is bleeding through :)
>> 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.
Makes sense.
>
>> 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/
Just to clarify - *meta-intel would contain our machine specific 
configurations for particular intel platforms, while *meta-x86 would 
contain image-like things that are generic to all x86 server platforms?
Not sure I understand why meta-x86 exists if 
meta-intel/mellanox/portwell/quanta are all on the top level. Meta-x86 
was simply a folder in my proposal.

-Dave