[Meta] Move to a forking workflow for GitLab CE development

This is a meta issue to track the problems blocking us from moving to a forking workflow in the GitLab CE project. We shouldn't be working in a pristine glass castle that's not representative of the experience GitLab.com users are having.

There are a few reasons we want to do this:

• Fewer branches in gitlab-org/gitlab-ce
• More representative of what users are struggling with, leading us to fix problems with the product that only crop-up when we're using it with a forking workflow like this.
• We'll be able to better handle contributions to the open source project since team members and contributors will both use a similar workflow.

Potential Problems:

• Builds may be slower (something we should fix)
• We can't restart builds for other people's projects if they aren't shared with the GitLab.org group
• Maybe harder to test a branch locally?
• You end up with a bunch of extra branches that never get deleted and are too annoying to delete
• Not as easy to have more than one person work on a branch, the fork owner will have to give permissions to their fellow team member(s) (bug or feature?)
• It’s hard to get to the fork project (for me it doesn’t show up in the Project selector unless I explicitly search for it), this may be because I use the Activity Feed as my default view
• Can’t track progress of a feature branch if an MR hasn’t been opened (this wouldn’t scale anyway once we have more engineers, maybe a feature?)
• The GDK hasn’t really been tested for this situation, except by myself and Jacob when he originally implemented the upstream workflow
• Change is scary!

cc: @DouweM @rspeicher

Not as easy to have more than one person work on a branch, the fork owner will have to give permissions to their fellow team member(s) (bug or feature?)

This is my biggest issue, as I find myself pushing changes to a repo directly when I work on docs. I find it easier than telling people to make changes, but then again this might have to do with my perfectionism :)

@axil that might be something we should solve with GitLab itself, e.g. with the Done button we've had suggested for inline comments.

Thanks for creating this @connorshea. It's really important.

The GDK hasn’t really been tested for this situation, except by myself and Jacob when he originally implemented the upstream workflow

Happy user, here

@axil You make a good point. If several people are closely collaborating it makes sense. If it's just a normal MR where someone asked for you to review docs it may be better to let them fix it as a form of learning, rather than doing it for them.

If it's just a normal MR where someone asked for you to review docs it may be better to let them fix it as a form of learning, rather than doing it for them.

Agreed. Most of the time I find myself fixing stylistic changes, something that will be solved eventually by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4900.

Well, now we know GitHub solved this issue

@DouweM @smcgivern Can we consider this again, please? Sid asked if we could move to this after the last summit which has been a while. It'd be great if we could improve the fork flow and using it will ensure that.

@dblessing is the request for us to move to a forking workflow now, and deal with the pain points until we fix them?

Or is it to deal with the pain points now (in the next couple of releases), so we can switch to a forking workflow once we've solved those problems?

I'm definitely open to prioritising the things blocking us from switching. I'm less open to switching when we know it will suck

@smcgivern The pitfalls are really rather minor. Several of us on the team have been using the forking workflow for months/years and it is fine. I suggest we switch and then fix the (minor) annoyances as they arise. Several are mentioned in this issue so we can fix those right away. However, the point of moving to this workflow is precisely to learn more about the pain points and ultimately improve the way the community interacts with us.

OK, I think my main issue is that I'd really love to be able to collaborate on these better, but people can always add access manually. Plus, if it's really unusable for us, we can always switch back.

What are the steps we need to take? Are we planning on using protected branches, or just telling people to use forks?

/cc @DouweM

@dblessing How do you deal with these issues?

• Builds may be slower (something we should fix)
• We can't restart builds for other people's projects if they aren't shared with the GitLab.org group

For me, personally, the biggest disadvantage is having to add a remote for each fork that belongs to someone I'm working with, if I would like to cherry pick commits or modify something. This is probably something I can get used to, but when someone asks 'Hey, can push this easy fix to my branch?' it may be a little cumbersome to do, each time.

@grzesiek you don't need to add a remote if you're not changing anything, although I agree that the collaboration case isn't great yet.

@DouweM

Builds may be slower (something we should fix)

I have no idea where this came from. I don't know that we have any evidence of that. Yes, builds are slow, but I don't think that has anything to do with forks or shared runners. We could always have an admin assign the GitLab specific runners to team forks - but that's a bit of an overhead.

We can't restart builds for other people's projects if they aren't shared with the GitLab.org group

If this is a big concern, have each person add the gitlab-org group as a member of the fork. In reality, how often are people pushing to each other's MR? It's a serious question - I've never really had the problem but I'm not working on the dev team daily.

I think that we should ask people to add the group to their fork anyway, until we come up with something better. Otherwise other people can't push to that branch, as well as the build problem.

@dblessing that sounds like a problem with GitLab we should fix :)

@dblessing I'm 99% sure builds are slower on forks, just look at how long it takes for the Pipeline to finish for MRs of branches on gitlab-org/gitlab-ce compared to forks. I think we throttle parallelization on the default shared runners so you can't run 20 builds at once unlike on the main project. We should have some way of sharing the "special runners" we use for CE and EE with forks of the projects.

@connorshea Oh...you could be right. Any GitLab admin can assign the GitLab runners to projects. That could be a near-term solution though it requires some manual work.

However, this is a problem that may be solved by CI triggering builds on MRs. That way, the upstream project will build a MR that comes from a fork. This would solve lots of pain. This is being considered in https://gitlab.com/gitlab-org/gitlab-ce/issues/23902

moved to gitlab#5411

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue