Direct conversion from GitLab upstream
The Heptapod Mercurial repositories for the Rails application and Omnibus have always been converted from the upstream Open Source version, a.k.a Community Edition, see theit marketing guidelines for terminology.
Originally, the Community Edition Git repository was upstream of the Enterprise Edition Git repository, but that was changed around version 12.3, with the CE repository relocated and now fed with periodic extracts from the EE repository.
Heptapod kept on converting from the CE repository, with the ill effects described in #594 (bearable) and worse, a garbled ancestry of release branches: instead of having a release (x-y-stable) branch starting over every month from the trunk, they are artifically stacked on top of each other. This causes artificial conflicts when trying to merge upstream changes in Heptapod in advance of the actual releases, and prevents us from following upstream continuously.
We should therefore convert/import directly from the true upstream, implementing ourselves the removal of the EE code, that we obviously haven't rights to redistribute.
Also, rebasing Heptapod on (a conversion of) the upstream trunk would pave the road for semi-automatic update from upstream (automatic merge performed by CI if tests pass).
Task list:
-
rebase of the Heptapod development branch onto a changeset equivalent to the conversion of the gca of upstream EE main branch and the 14-10-stable branch (called below the 14.10 branching point. The corresponding Git commit does not really exist in gitlab-foss
. We don't want to convert again ancestors of the branching point, because- we already have the code, and don't want to create more than 200 000 changesets for no purpose
- in versions prior to 12.3, there is no reason for the EE code to be in the same separate directories as it is currently. Cutting at 12.3 would be no simpler than at 14.10.
-
patched hg-git able to produce the same results as the GitLab exporter of EE to CE -
direct import of the Git EE commits that are not descendents of the branching point but are ancestors of the upstream trunk (branches started before the branching point and merged after, dubbed anterior merged ramifications). This is necessary to prevent hg-git importing the whole repository. A fixed list is good enough for the time being. As we are about 2 months after the 14.10 EOL, chances are that no new anterior merged ramifications will appear (contributors being probably asked to rebase on a current commit). -
automated validation: a script to check the release tags we get at the end of the process should have the exact same content as in the gitlab-foss
upstream repository (we cannot compare intermediate commits). It would be safer to leave the converted changesets in the draft phase until there is a tagged release to compare, but that has strong implications on the development workflow (non-publishing MRs, which are not currently available in Heptapod). -
at least a way to guard against importing ancestors of the branching point (will happen if a new anterior merged ramification appears) -
continuous operation, using the patched hg-git and the automated validation above.
Continuous merge of upstream in Heptapod would be another issue.