Managing openbmc with subtree

[Dave Cobbley]

I posted an initial draft of what permissions could look like in the top 
level meta-data.

https://gerrit.openbmc-project.xyz/#/c/openbmc/openbmc/+/11730/

This will require additional people receive +2 permissions, but the 
OWNERS plugin will ensure that a patch cannot get merged unless it has 
+2 from the appropriate people.

Thanks,
-Dave
>> On Jul 19, 2018, at 4:08 PM, Dave Cobbley <david.j.cobbley at linux.intel.com> wrote:
>>
>> Brad,
>> Trying to identify the appropriate work-flowfor using git subtree to maintain all the meta-data under openbmc.
>> I'm imagining something like:
>>
>> 17 subtrees
>> ** indicates an actual folder, not subtree.
>> meta-openembedded/
>> meta-raspberrypi/
>> meta-virtualization/
>> poky/
>> **meta-openbmc-machines/
>> ** meta-arm
>>     ├── common
>>     └── meta-qualcomm
>> **meta-evb
>>     ├── meta-evb-aspeed
>>     ├── meta-evb-nuvoton
>>     ├── meta-evb-raspberrypi
>> **meta-openpower
>>     ├── meta-ibm
>>     ├── meta-ingrasys
>>     ├── meta-inventec
>>     ├── meta-rackspace
>> **meta-x86
>>      ├── meta-intel
>>      ├── meta-mellanox
>>      ├── meta-portwell
>>      └── meta-quanta
>> **meta-openbmc-bsp/
>>      ├── meta-aspeed
>>      ├── meta-ibm
>>      ├── meta-nuvoton
>> meta-phosphor/
>>
> This is a great picture, thanks.  My longer-term vision is a bit more like this:
>
> meta-openembedded/
> meta-virtualization/
> poky/
> meta-arm/
> meta-openpower/
> meta-x86/
> meta-phosphor/
>
> Or even ditching Yocto and just using OE-Core/bitbake directly:
>
> meta-openembedded/
> meta-virtualization/
> meta/
> bitbake/
> meta-arm/
> meta-openpower/
> meta-x86/
> meta-phosphor/
>
> I could understand a case for including the BSPs in the base distro:
>
> meta-openembedded/
> meta-virtualization/
> meta/
> bitbake/
> meta-arm/
> meta-openpower/
> meta-x86/
> meta-phosphor/
> meta-aspeed/
> meta-ibm/ -> for our SOCs only, not servers
> meta-nuvoton/
> meta-raspberrypi/
>
> The main thing to notice with all of these is I’ve removed meta-foo from
> meta-openpower, meta-x86 and meta-arm.  This lets people have arm, power
> and x86 servers all in the same layer or repo if they want:
>
> meta-xyzcorp/
>     |— meta-arm-server/
>     |- meta-x86-server/
>     |- meta-power-server/
>
> Actually I’ve removed them from the repository completely.  I think we
> need some kind of reference platform(s) just like Yocto.  Otherwise we are
> going to wind up with too many server-layers in the distro.
>
> Another idea is to scrap meta-openpower, meta-arm and meta-x86
> and put all that content in meta-phosphor:
>
> meta-openembedded/
> meta-virtualization/
> meta/
> bitbake/
> meta-phosphor/
>
> What do you think of all this?  There is a lot of change here, so some
> staging would be required.  Obviously all ideas are debatable.
>
>> I began working on the workflows that a typical dev would do to check code in and have Jenkins automatically update the top level repo with the new additions, but run into troublewith a merge commit.
>>
>> 1. git clone openbmc-openbmc
>> 2. #make changes
>> 3. git add
>> 4. git commit...
>> 5. git subtree push --prefix=path/to/local/subtree ssh://openbmc.gerrit/openbmc/<subtree_name> HEAD:refs/for/master
> Looks good to me.  This should be pretty similar to the workflow
> for OE-Core -> Poky right?
>
>> At this point, the build CI would run it's normal operations and code review would take place.
>> Following a +2 and submit, Jenkins would:
>>
>> 1. cd openbmc-openbmc
>> 2. git pull
>> 3. git subtree pull --prefix=path/to/subtree --squash <remote> master #For all given subtrees
> I think I read somewhere that Poky has another verification and approval
> step here, before merging OE-Core/bitbake patches into Poky.  Do we want
> to be like Poky and require testing and/or maintainer approval here?
>
>> However at this point, I end up with two commits in the parent repo, one with the squashed changes, and a merge commit.
>> I don't know how to do this operation without ending up with a merge commit, do you have any advice here?
> To avoid the merge you can skip the subtree pull (which does a merge) and
> instead generate a patch:
>
> git cherry-pick —strategy=subtree -Xsubtree=path/to/subtree <squash-commit>
>
>> I could be totally overthinking the whole strategy,
> I don’t think so.  Its par for the course I think for an OE based distribution.
>
>> so any advice and direction is much appreciated!
>> Along those same lines, is subtree still the correct tool?
> I think so.  I had a look at Combo-layer awhile back…it seems to do the
> same thing as git cherry-pick, that is, generate patches and apply them
> to the parent repository.  It does layer some features on top of that
> but I haven’t missed those yet.  They are similar enough I feel we could
> switch back and forth if need be.  I’m guessing Combo-layer was written
> before subtrees had the support they do today in Git.
>
>> I hear repo works for a lot of projects, Yocto uses https://wiki.yoctoproject.org/wiki/Combo-layer.
>>
>> Thanks,
>> -Dave
> Thanks for kicking off this conversation!
>
> -brad