One thing I'm a little unsure of: sub-sub-modules - currently 3 of the deployed submodules have their own submodules:

• ./vendor/zordius/lightncandy/
  • https://github.com/mustache/spec.git
  • https://github.com/kasperisager/handlebars-spec.git
• ./extensions/VisualEditor/
  • https://gerrit.wikimedia.org/r/p/VisualEditor/VisualEditor.git
• ./extensions/Collection/
  • https://gerrit.wikimedia.org/r/mediawiki/extensions/Collection/OfflineContentGenerator

In T98834#1279062, @mmodell wrote:

One thing I'm a little unsure of: sub-sub-modules - currently 3 of the deployed submodules have their own submodules:

• ./vendor/zordius/lightncandy/
  • https://github.com/mustache/spec.git
  • https://github.com/kasperisager/handlebars-spec.git

We don't actually deploy those submodules since the zipball composer gets doesn't include them.

Oh, interesting.

But that still leaves VisualEditor and Collection... I'll have to either subtree-merge those or keep them as submodules.

Just making sure. Are you referring to git subrepo in this task? If so, as per its spec, sub-sub repos are supported as well (according to its docs, at least).

@mobrovac: yes that's the git-subrepo I am testing out currently. I didn't see anything about nested subrepos, where did you find it documented?

Also, I'm not too thrilled about the fact that it's written in bash, but it's a joy to use and I really like the general model, it seems to get the best features of submodules without the headaches.

In T98834#1285419, @mmodell wrote:

@mobrovac: yes that's the git-subrepo I am testing out currently. I didn't see anything about nested subrepos, where did you find it documented?

From https://github.com/ingydotnet/git-subrepo/#benefits : Subrepo repositories can contain subrepos themselves

Also, I'm not too thrilled about the fact that it's written in bash

True, but at least that allows for quick, painless and no-deps install and set-up, which given that we plan to use it for prod deployments, is a big plus IMHO.

but it's a joy to use and I really like the general model, it seems to get the best features of submodules without the headaches.

Yup, +1 from me as well.

Following up from a conversation we had in #wikimedia-releng on irc (CC'ing interested-parties):

One thing that I would have to come up with a solution for is how to add the VisualEditor/lib/ve subtree - if visual editor extension used git-subrepo to merge in lib/ve then it wouldn't be a problem. I'm sure I can come up with a different work around if the VE team objects to the idea of using git-subrepo, but that would probably be the easiest way to handle it if we go the route of git-subrepo for release branches.

My experience so far is that git subrepo pull --all is quite slow. I don't think it's any slower than make-wmf-branch but it's not much faster. I certainly would like to see a significant improvement there but I'm not sure there is any solution - there are so many extensions, any way you go about it is bound to be a little slow.

In T98834#1331975, @mmodell wrote:

Following up from a conversation we had in #wikimedia-releng on irc (CC'ing interested-parties):

One thing that I would have to come up with a solution for is how to add the VisualEditor/lib/ve subtree - if visual editor extension used git-subrepo to merge in lib/ve then it wouldn't be a problem. I'm sure I can come up with a different work around if the VE team objects to the idea of using git-subrepo, but that would probably be the easiest way to handle it if we go the route of git-subrepo for release branches.

Merging one of the (possibly many) integrations of VisualEditor (VE-MW) into the main stand-alone VE repo, or mastering VisualEditor inside said integration, is a pretty strong "please, no" from our end. Do you have a better solution?

@Jdforrester-WMF: It wouldn't necessarily have to take place in the main VE repo, this could be done via an intermediate merge repo that simply merges the subrepo and then gets merged into mediawiki/core.

This is really a detail specific to the wmf release branches of mediawiki, it will really only come into play when applying commits from the various extensions to the wmf releases.

Also, this may not have been stated clearly: this is an experiment - I'm not demanding any changes from the editing team, it's really just an idea I'm exploring to see if it really solves the problems identified in the task description, and whether it solves more problems than it causes.