2 patch dependency

[Brad Bishop]

Sorry - been a bit behind on email lately.

>> Ooh.  Was this talked about on the mailing list somewhere?  I've gone
>> back through at least August and haven't come across it.  Was there
>> an exploration of moving to `repo` instead?
> 
> May have only been IRC, I’ll let Brad handle this one. I just know
> that my vote is to get away from subtree. It made the dev process
> more difficult/complex and it doubled the required capacity of our CI
> infrastructure.

Right…I didn’t think this had left my head.  Apparently I told Andrew about it :-)

A brief history lesson for any that aren’t aware - the original workflow was patches were submitted to openbmc/openbmc for subtrees where we are as far upstream as you can get.  We moved from that to the workflow we have today because of a desire of mine and others for de-centralized ownership of metadata.

To enable that I proposed the same process that the Yocto project uses to aggregate the various sub-projects into the poky distribution.  This is how we wound up with the workflow we have today.  In hindsight this was a mistake.

The proposed change would simply be that we revert back to the old workflow, which was much simpler, and use the Gerrit plugin to implement the de-centralized ownership requirement.  There have been and will be a couple enhancements since we last used that workflow though:

1 - I track poky/meta-openembedded head. Last time we tracked the latest released version.  This has worked fine; I am not aware of a single instance of upstream breaking us or causing any instability.

2 - I would automate the subtree pushes. Last time this was done manually (and thus the subtrees were often stale).

As far as repo goes - in my mind that is something completely separate.  If anyone wants to maintain a repo manifest somewhere I don’t have a problem with that.  It doesn’t have to have anything to do with the patch submission workflow.

thx - brad