Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Merging CE and EE codebases

On this page

Resources

Blueprint: Working in CE and EE codebases

Related issues:

Overview

In Blueprint: Working in CE and EE codebases, we have the current development workflow described using the graph:

CE-EE-Development-and-Release

In this document we will look into what steps are necessary to get CE and EE codebases merged into one, to simplify the workflow to:

Single-Codebase

From all the discussions points raised in related issues and the blueprint, several items are worth highlighting:

  1. Backend code requires some work to separate licensed and unlicensed code
  2. Work on the frontend code requires vast amount of work
  3. Merging two sets of documentation
  4. There needs to be a clear single owner coordinating this effort with the stakeholders
  5. Transparent communication with the wider community and customers about the pending codebases merge is required
  6. Preparing the projects structure to allow for seamless releases and possibly project containing only FOSS code

Work on the first three items would be beneficial to reducing merge conflicts, regardless of whether the codebases get merged.

Backend code changes

Backend epic is describing current work requirements.

Yorick Peterse worked on number of items in 11.6, 11.7 and 11.8 milestones, reducing the remaining work.

Based on the rough estimates Yorick made in the individual issues, one experienced Backend developer would need to spend approximately:

This work is only a rough estimate but in general we could expect that one experienced Backend developer would need up to 4.5 months to complete the work necessary to separate EE proprietary backend code alone.

Frontend code changes

Frontend epic covers some details on what is required to create a separation between the CE and EE code for all frontend assets. The effort does not appear to be small:

Frontend team has architecture guide which mentions architecture experts. Having an architecture expert who is also familiar with releases, such as Filipa Lacerda dedicated to scoping and defining the challenge for at least one release cycle would help us better at understanding the required work.

Licensing all frontend assets under MIT license would however, potentially reduce the amount of work as there would be no need to make architectural changes as all frontend assets could be freely used even in a FOSS repository.

Merging documentation

Documentation is licensed under CC-BY-SA.

The idea of merging documentation is not new, it was raised in gitlab-ce/22617 and once more in gitlab-ce/53367.

Last time some investigation was done, a test MR was created. This will need to be done once more to have a more up-to-date status, but based on the previously mentioned MR it appears that the vast majority of the work is going to be:

Achilleas Pipinellis has started towards this goal in gitlab-org&199 so moving towards documentation merge could be accelerated by continuing/building on this work with higher priority.

Create new project structure and tooling

Number of tools we use day to day to develop and release GitLab are tied to the two project system that we have in GitLab CE and EE. It is necessary to start working on strategy and orchestrate changes the tooling we use for releases. A plan on releasing a FOSS project derived from a single codebase should also be considered to ensure that the possible community expectation of FOSS only project is satisfied.

Douwe Maan had a good suggestion in how the new project structure could look like. The scope of that suggestion could be reduced however, or possibly iterated on:

Coordination

As shown in gitlab-ee/2952 and above, we have a lot of interest in resolving this challenge. One of the biggest challenges when tackling an important change such as this, is having a single point of contact to coordinate the efforts.

Coordination needs to happen between:

Customer and Community relations

Merging open source codebase with a proprietary codebase is likely to generate a lot of publicity. There are ways in which this change could be considered a move against the FOSS philosophy so it is necessary to gather feedback and listen to the trends that this change could bring. Regular communication will be the key for having a seamless change.

Initial blog post can reuse the related blueprint and this design document:

Starting the work

In conclusion, to start this work we need to:

Open source repo

We run a periodic job that does a git subtree on the main repository to extract a pure open source version that is available to clone from.