Topic on Talk:Wikimedia Release Engineering Team/GitLab

A very constructive way that folks could help with this migration would be collect various "typical" pull request workflows and document their implementation as well as pros and cons. Gerrit is highly opinionated in how to use git for code review. GitLab/GitHub provides a lot more flexibility, which can be nice, but can also be a burden. If we end up with 200 repos and 50 different workflows that will in itself be a large impediment to some of the hoped for gains from moving to a more widely used git hosting and code review platform.

I think in an ideal world we would end up with consensus on a "preferred" PR based workflow that projects would be encouraged to adopt. Forcing a single workflow across all projects is itself not ideal, but having a standard process will make it much easier to explain how project/repo X differs from that Wikimedia standard practice and why.

I like this, @BDavis (WMF). I tend to look at these things as opt for the default for simplification of development, onboarding, documentation, etc. unless there is truly something unique about a particular repo. PR workflows are not an area of innovation for us, so let's try to let others trod the path before us.

+1 to having a standard workflow.

Would we be using a forking workflow (e.g. there is a canonical mediawiki/core repo, and my fork is kostajh/core, so then I submit merge requests from my fork) or their recommended approach that developers have write access to push branches to a single repo?

Then we should also talk about whether we would use their recommended GitLab flow (which seems kind of complicated) or Github Flow which seems to track what we currently do in Gerrit, e.g. there is a master branch and then patchsets ("feature branches") are merged into that, and master is what is deployed. I guess some of this depends on what the future holds for continuous integration / continuous deployment workflows.

In Gerrit, collaborating on a patch is kind of awkward. AFAICT, you can either push your change directly to the patchset, which is complicated because maybe the first developer doesn't agree with what you've done. Or you can push a patch on top of theirs, but then it doesn't actually get merged in until everything else in the chain does, so it is kind of awkward. Or you can leave inline comments with suggestions which is cumbersome.

In GitLab, I noticed they have a really cool feature where you can generate an inline suggestion that the user who created the merge request can then decide to accept or decline. I don't know what that looks like in terms of git history, authorship, and workflows (or if it is supported in GitLab CE), but I did want to raise it as a something that would be really nice to support as part of whatever standard workflow we adopt.