Blueprint: Working in CE and EE codebases
In Blueprint: Working in CE and EE codebases, we have the current development workflow described using the graph:
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:
From all the discussions points raised in related issues and the blueprint, several items are worth highlighting:
Work on the first three items would be beneficial to reducing merge conflicts, regardless of whether the codebases get merged.
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 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.
Documentation is licensed under CC-BY-SA.
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:
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.
gitlab-org/gitlab-cewould be deprecated, issues moved to
gitlab-org/gitlaband any usable MR's ported
omnibus-gitlabwhere proprietary code would need to be removed when packaging
gitlaband the transition
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:
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:
In conclusion, to start this work we need to:
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.