2 patch dependency

[Patrick Williams]

On Fri, Nov 22, 2019 at 01:41:14PM -0500, Brad Bishop wrote:
> 
> > On Nov 22, 2019, at 12:36 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
> > 
> > Can you elaborate briefly on the issues you've had with it?  
> 
> Well for one, the issue that started this thread - coreqs.  they are harder than they need to be with the current workflow.
> 
> Also the two step CI verification that comes with it is not good - it halves our already limited resources.  Although now that I think about it I don’t recall why we felt this was necessary…

I understand the co-req issues.  We'll still have them between code
repositories (which was really the underlying issue in this case).  But,
eliminating the sub-trees certainly alleviates one introduction of them.

To be clear, I personally have no attachment to the sub-trees or mono-repo
from an openbmc/openbmc perspective.  Just trying to offer alternative
ideas before there are changes.

By "already limited resources", I assume you mean compute resources for
CI.  It seems with the companies involved in this project, this should
not be an issue... is this something the TSC should discuss?

> Finally it is just awkward and lame to clone openbmc/openbmc, hack on it, and then have mess around with adding additional remotes and doing subtree cherry-picks, etc… to submit a patch.

No disagreement at all here.

> > It seems 
> > like many metas with subtree, many metas with repo, or mono-repo all have
> > advantages and disadvantages and are just different ways people have
> > attempted to skin the same animal.  
> 
> Could we not have all of them at the same time?
> 

This is entirely a "without evidence" statement but my intuition would
be trying to do all of them gives you all the disadvantages and few of
the advantages...

Perhaps a higher-level discussion is what purpose do the meta sub-trees
serve and is it worth the project investment in them?

My recollection was that people asked for sub-trees (the old split back out
of openbmc/openbmc method) because they wanted to pick up some subset of
recipes to use in other projects.  Why should our project's day-to-day
activity be less efficient to satisfy that?  (+1 to mono-repo).

I recognize the subtree maintainers desire was a reason for moving to
that structure, which maybe this MAINTAINERS plugin addresses.

> > This would be one advantage of using repo.  
> 
> The word advantage implies repo would replace something else.  What do you want it to replace?

Good point.  A repo manifest could replace the current combined metas
that is openbmc/openbmc and keep today's subtree maintainer model as-is.
Again, I was just trying to present it as an alternative to going back
to the "old model" of openbmc/openbmc being the master.

> 
> > You can have different
> > manifest files for the different Yocto branches.  That way we can keep
> > pointing to an LTS Yocto but with newer OpenBMC code (for people who
> > might desire that when putting OpenBMC into production).
> 
> makes sense.
> 
> > 
> > 
> >> 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.
> > 
> > I'm not really following how any of the options have a big impact on patch
> > submission workflow.  
> 
> agreed.  In fact…is there anything you need from the community to start maintaining a repo manifest today?  I don’t think there is, is there?  Maybe a git repo to put it in?
> 

There are two scopes to a potential repo-manifest (in the context of
this project specifically):

   1) A manifest that combines the meta-subtrees into a single
      directory tree.

   2) A manifest that combines openbmc/openbmc plus the project's code
      repositories into a single directory tree.

If we are going back to a "openbmc/openbmc is the primary source" model
#1 is pointless.  Also having an alternative Yocto branch is difficult
without #1.

Yes, #2 can be done today (with a new repository).  I think it would
mostly be a developer-help initially but could be rolled into
simplifying CI.  (We could also do #1 and #2.)

I'm mostly focused on #1 in this email thread because has impacts to
this subtree elimination proposal.  It is probably worth another thread
if we want to discuss #2 in more detail.

> > Most developers just contribute to whatever
> > repository is considered the "master" of where they're making changes.
> > If that is a subtree or a monorepo, does it really have much bearing?
> > (I guess it has impact in the cases where we need to span what are
> > currently subtrees?)
> > 
> > Having a repo manifest simplifies two things:
> >    1. Implementation of cross-repo CI (and the topic-based testing I
> >       mentioned) because there is a clear assembling of all the git
> >       repositories that might be impacted by a topic.
> > 
> >    2. A mechanism for developers to "get all the code".  I've heard
> >       complaints of developers having to manually assemble a collection
> >       of git-clones for all the different sub-projects they tend to
> >       work on.  A maintained manifest of all the openbmc/* repositories
> >       would alleviate this.
> 
> I think you are driving at a couple things:
> 
> 1 - patch submitters should continue to submit patches to meta-*, poky, meta-openembedded, etc.
> 2 - you start maintaining a repo manifest.
> 3 - everyone will abandon the current monorepo composed of subtrees.
> 
> Do I have it right?
> 
> What I’m asking for instead is:
> 
> 1 - patch submitters submit patches to openbmc/openbmc (unless there is an upstream community)
> 2 - patches (immediately) find their way into meta-* via automation
> 3 - you start maintaining a repo manifest
> 4 - I continue to maintain a monorepo composed of subtrees (the ones with upstream communities) & directly submitted patches
> 

I think we're on the same page with both of these last two "processes"
you wrote.  Hopefully my #1/#2 above clarifies my thinking.  Except "you
start" doesn't have to be *me*, but I could certainly pull together a
manifest file pretty quickly.  (As in, I don't need to 'maintain' it but
I can put in some effort to get the ball rolling.)

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191122/ca0d2537/attachment-0001.sig>