Topic on Talk:GitLab consultation

A few observations from discussions here and on mailing lists:

• Gerrit is a (mostly) known thing already (as in -- we know what it looks like, how it functions, what the strengths and weaknesses are, although we could debate them)
• Not a ton of people use GitLab in their daily workflow, so it's harder to make judgments about UX, strengths and weaknesses for code review, etc.
• A lot of people use or have used GitHub and are familiar with its code review model, the UX, etc
• It seems that many people assume (maybe not correctly?) that GitLab would be more or less just like GitHub

Given the above, it seems like it would be useful to have some small pilot projects that use the test instance to help us better assess how well GitLab's code review tooling would work for us. So far https://gitlab-test.wmcloud.org/explore shows 1 merge request among the repos that have been created. I think if we (i.e. collectively most everyone who has commented or cared about this proposed move, especially those of us who are skeptical of switching to GitLab) tried to use the test instance for a few tasks, for core or an extension, it would provide a lot more concrete information on the strengths/weaknesses of using it. @EGardner (WMF) and @ATomasevich (WMF) did a similar workflow with GitHub, while working on the Vue port of MachineVision; you could make your merge request in the GitLab test instance for a feature / bug you're working on, then at the end clean it up and resubmit to Gerrit for a final merge. It's duplication of work but could provide us useful experience IMHO.

In theory it wouldn't be too hard to have quibble running on merge requests for core or extensions, I don't think.

Anyway, curious to hear what others think about doing something like this, and how we'd go about organizing it.

This seems like a great way to surface more of the experience. I'd be happy to try it out for stuff we're working on within RelEng, though I'm guessing it'd be more useful for folks who work directly on MediaWiki and extensions to trial some code reviews.

Let me know if I can help in any way from the administrative end, or if bugs crop up in the configuration / setup.

I second this proposal, and would happily volunteer to be a guinea pig at some point in the future (assuming I'm working on a feature amenable to this approach). There are aspects of Gerrit I appreciate, but it was nice to return to the more familiar GitHub/GitLab workflow for the MachineVision project. For one thing, I think that the tools GitLab will provide for actually browsing and reading through code are much better than what Gerrit offers. I have never been a fan of the Gerrit / GitTiles integration, and generally rely on GitHub mirrors when I actually want to navigate a codebase.

If you could be a guinea pig during the consultation window that'd be very helpful -- happy to setup CI/repos/ACLs: whatever's needed over the short term.

Would you actually have to pay for GitLab even if we use our own servers to host/run it? If so, how much? Do we have to pay for Gerrit?

@MarcoAurelio the proposal would be to use the test instance we already have set up https://gitlab-test.wmcloud.org/ . AIUI we don't pay a license for GitLab as we are using the community edition, and neither do we pay a license for Gerrit. The time/resources needed to maintain the Gerrit/Jenkins/Zuul setup is probably another story though :) (and I have nod idea how that would compare with maintaining code review + CI tooling for GitLab)

@KHarlan (WMF): Thanks for clarifying. Have a nice day.

So, a rough proposal for how to proceed here:

1. We add fresh clones and at least basic CI on gitlab-test for:
   1. mediawiki/core
   2. some appropriate extension
2. Interested parties use these for reviewing a handful of real changes and experiment with workflow

It seems like there are a couple of broadly viable workflows:

1. Developer pushes to a branch on the primary copy of the repo which then becomes a merge request
2. Developer forks the primary copy of the repo to their account, pushes to a branch on their fork, and creates a merge request from there

In practice #1 might be the default for known, trusted contributors who have write access to the repo (the equivalent of +2 rights), while #2 might be the path for new volunteer contributions. (More fine-grained distinctions are possible with roles, but I haven't explored how that works in depth yet.)

Within those broad approaches, we've identified some unanswered questions:

• How should we configure merge commits?
  • Merge commit for every merged MR
  • Merge commit with semi-linear history
  • Fast-forward merge, no merge commits, rebase required if no FF is possible
• Should multi-commit MRs be squashed into a single commit by default?
  • Should this be mandated or optional?
• Matters of culture/convention
  • How granular should MRs be in general?
  • There's a feature that allows pushing changes to a MR if you're allowed to merge, even if it's on another user's fork - echoing the ability in Gerrit to update someone else's patchset. Worth enabling by default?

I can imagine most of those answers varying by project/team, but they seem like the sort of thing that's worth exploring on the test instance.

We got a basic CI pipeline with Quibble working for mediawiki/core earlier. If this seems like a fruitful way to proceed, we can start with a clean copy of the repo and do the same for an extension.

Thoughts? Volunteers to work through a few changes on gitlab-test? What would make a good extension to use for this exercise?

Thanks Brennen.

Given this is an important part of the conversation and we want people to engage and test out and help us determine how we can make GitLab workflows work best for us, I've cross-posted this on the old talk page's "feature requests" thread.

My team is trying something like this at the moment. We've forked https://gitlab.com/wmde/mediawiki-extensions-VisualEditor/ , and are actively developing on branches. We're collecting our impressions internally and will come back here to report our shared conclusions.

We've started roughing out some workflow documentation at GitLab consultation/Workflows. At the moment it's much more basic than I'd like, I think partly because it's hard to make preemptive recommendations about optimal workflows for people coming from Gerrit without more experimentation.