Managing openbmc with subtree
Dave Cobbley
david.j.cobbley at linux.intel.com
Thu Aug 9 08:14:35 AEST 2018
>> 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 - 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
More information about the openbmc
mailing list