This will merge the extensions into the deployment branch of mediawiki core, rather than branching and cloning 100+ submodules each week. Changes to the extensions would be merged into the relevant deployment branches of mediawiki/core. Branches can be used in the extensions to track deployed changes, but this wouldn't be necessary since the core deployment branch would be tracking the deployed changes.
Advantages:
1. Branching of extensions could be simplified.
1. Extension developers / maintainers control the branching and tagging of their code, no auto-generated branches cluttering up the repos.
1. One view of deployed code - the git history of the deployment branches clearly shows the history of what changed in core as well as the extensions.
1. Hotfixes to either core or the extensions show up as squashed merges into the deployed branch in one linear history.
1. Easier patch management for security patches as all patches could be continuously maintained, rebased on top of the deployed branch. Eliminates a significant patch management overhead for release engineering.
** //This also eliminates significant risk of human error in the process.//
1. The process of branching for deployment on Wednesday will be significantly faster: between patch management simplification and faster branching, I expect to save somewhere between 30-60 minutes every week.
1. swat deployments should be easier as well. Instead of cherry-picking a patch and then updating the submodule pointer in a separate commit, you would just propose the patch to the deployed branch directly and you wouldn't need a separate submodule bump commit.
I'm not entirely sure how to make the transition to the new setup, or how to get people familiarized with it and comfortable with sub-repos. To start with I need to publish my example repo so that interested parties can see what the git history looks like with this arrangement. After that I don't really know what the next step is going to be, suggestions are welcomed.