The team at GitLab is now considering to move towards a single Rails repository by combining the two existing repositories. Although the GitLab Community Edition code would remain open source and MIT licensed and also the GitLab Enterprise Edition code would remain source available and proprietary.
The challenges with having two repositories?
The Ruby on Rails code of GitLab is currently maintained in two repositories. The gitlab-ce repository for the code with an open source license and the gitlab-ee repository for code with a proprietary license which is source available. Having two similar but separate repositories, can make feature development difficult and error-prone while making any change in GitLab.
To demonstrate the problem, the team at GitLab has given a few examples:
Duplicated work during feature development
The frontend only Merge Request needed a backport to CE repository. Backporting requires creating duplicate work in order to avoid future conflicts and changes to the code to support the feature.
A simple change can break master
A minor change in CE repository failed the pipeline in the master branch.
Conflicts during preparation for regular releases
There might be conflicts during preparation for a regular release, e.g. 11.7.5 release. Merge requests for both the CE repository and EE repository need to be created. And when the pipelines pass, the EE repository would require a merge from the CE repository. This would cause additional conflicts, pipeline failures, and similar delays during which the CE distribution release also would get delayed.
Steps taken by GitLab team to improve the situation
Before 2016, merging the CE repository into the EE repository was done when the team was ready to cut a release and the number of commits was small so it could be done by one person. As the number of commits between the two repositories grew in 2016, so the task got divided between seven developers who were responsible for merging the code once a day. This worked fine for some time until delays started happening due to failed specs or difficult merge conflicts.
The team then merged an MR that allowed the creation of automated MRs between the two repositories by the end of 2017. This task ran every three hours, which allowed for a smaller number of commits to be worked on. The number of changes going into CE and EE repositories grew to thousands of commits in some cases by the end of 2018. This made the automated MR insufficient. The Merge Train tool was then created to automate these workflows further and which automatically rejected merge conflicts and preferred changes from one repository over the other.
What is the GitLab team proposing?
The gitlab-ce distribution package consists of gitlab-ce repository which offers only the Core feature set. The gitlab-ee distribution package consists of gitlab-ee repository. The change which the team is considering proposing would be to merge the gitlab-ce and gitlab-ee repositories into a single gitlab repository.
The design for merging two codebases requires the work and process changes in detail. Though the proposed change would pertain only to the Ruby on Rails repository.
Expected changes
- The gitlab-ce and gitlab-ee repositories may be replaced with a gitlab repository, with all open issues and merge requests moved into the single repository.
- All frontend assets such as JavaScript, CSS, images, views will be open sourced under the MIT license.
- The proprietary backend code will be located in the /ee repository.
- All the documentation that will be merged together will now clearly state which features belong to which feature set.
The downsides
The GitLab team was clear about the possible downsides of this approach:
- Users with installations from the source are currently cloning the gitlab-ce repository. The clone will also fetch the proprietary code in /ee directory.
- The database migration code is open source and does not require additional maintenance so there is no additional work required.
The team is now exploring better ways to solve the problem of busy work and plans to bring improvements to the current proposal.
To know more about this news, check out the post by GitLab.
Read Next
Introducing GitLab Serverless to deploy cloud-agnostic serverless functions and applications
