Managing openbmc with subtree

[Brad Bishop]

> On Aug 1, 2018, at 5:53 PM, Dave Cobbley <david.j.cobbley at linux.intel.com> wrote:
> 
> 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/

At first I was OK with this idea but instead of rushing to something
I’d like to slow down for a sec and be sure we don’t like the other
options.

My issue with 11730 is that we wind up with different workflows for
updating the different subtrees - for example updating meta-virtualization
is different than updating meta-phosphor.

If we go back to your original workflow where the developer pushes directly
to the subtree repository instead of openbmc/openbmc, recall we were stuck
on how to do it:

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


Elaborating on my suggestion from before - here is a possible workflow.

Consider a repository with two remotes:

$ cat ~/.ssh/config
Host openbmc.gerrit
        Hostname gerrit.openbmc-project.xyz
        Port 29418
        User user
        IdentityFile ~/.ssh/my-gerrit-key

$ git remote -v
meta-phosphor-gerrit    ssh://openbmc.gerrit/openbmc/meta-phosphor (fetch)
meta-phosphor-gerrit    ssh://openbmc.gerrit/openbmc/meta-phosphor (push)
openbmc-gerrit  ssh://openbmc.gerrit/openbmc/openbmc (fetch)
openbmc-gerrit  ssh://openbmc.gerrit/openbmc/openbmc (push)

You can make and commit changes as usual.  When it comes time to push for
review:

$ 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

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.

Granted it is a couple extra commands, but it seems like something that could
be scripted pretty easily.  Thoughts?

-brad

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