Skip to content

Evaluate moving to GitLab for merge requests

We’ve added #14516 to our 2018 roadmap. I think this ticket is strongly related but it’s too premature to be part of that roadmap item, so let’s track it separately.

A few observations lead me to create this ticket:

  • My experience welcoming new Tails contributors: we spend lots of time teaching new contributors how we use Redmine for submitting proposed changes. Symmetrically, given the amount of questions they ask and mistakes they do, it’s clear that new contributors spend lots of time learning our workflow. I suspect this requirement raises the bar to a point that discourages some potential contributors who would be happy to fix a small bug or a couple typos, but are not ready to learn a workflow that they will have no use for anywhere else.
  • My experience as a drive-by contributor elsewhere: as a free software user, pretty often I notice a small bug or typo that I could very easily fix. The chances that I actually submit a fix depends in great part on whether the affected project uses a well-known workflow. If it does, then generally I’ll bother clicking a “Fork” button and submitting a merge request, e.g. https://github.com/ModernPGP/modernpgp.github.io/pull/9. If it doesn’t, then generally I’ll be lazy and give up. I suspect many people act similarly but I have no data to back this guess. Nowadays, a “well-known workflow” basically means a GitHub or GitLab web interface; using github.com or gitlab.com eases things even more for people who already have an account there, but IMO the need for creating an account is not that much of a problem as long as one knows they’ll be at ease in the interface once logged in.
  • Modern web-based merge request workflows provide a better UX for reviewers and contributors. I’ve been using GitLab more and more for other projects and some features are life changers in my experience:
    • inline commenting on the specific piece of code one is reviewing and direct access to the submitted code from the same interface where the merge request is tracked, regardless of the status of the submitter (in our Redmine we have a list of commits but that only works if the submitter flagged them appropriately and has commit access to our official repo)
    • a concept of having N open “discussions” on a merge request, that can be “resolved”: compared to the linear list of comments without metadata that we have on Redmine, it makes it much easier to know what’s left to address, because whatever has already reached a conclusion is hidden by default
    • A great lot of people still prefer using a Terminal as much as they can but I’m also convinced that this set of people is getting more and more marginal, so probably we should not optimize our contributors workflow for them: our future new contributors are much more likely to be at ease with GitLab or GitHub than with our current workflow. Anyway, one can talk with GitLab using email.

So far so good. I’ll ignore GitHub as I’m sure a proposal to move there would never reach consensus in our community so I’ll focus on GitLab.

The problem is, these tools perform optimally when one uses them for issue tracking as well as merge requests. There are some options to integrate Redmine issue tracking with GitLab merge requests, but I don’t think this combination would give us the advantages we’re looking for in terms of improving new and current contributors experience: current contributors would have to learn GitLab, new contributors would have to learn Redmine, and everyone would still have to gain and maintain knowledge about a weird workflow nobody else uses.

GitLab’s issue tracking has a very different set of features from Redmine’s. It may be too limited for our needs even if it’s improving (e.g. GNOME successfully got some features released in the “community” open souce version of GitLab, that were previously available only in the “enterprise” proprietary version). E.g. relationships between issues is not in the free software version (upstream bug, the set of metadata available for issues + the lack of complex search queries may prevent us from doing the kind of fancy stuff we’ve got used to on Redmine. So likely our most involved contributors would need to adapt a lot to the new set of features and concepts, in particular when working on, or managing, a large project. See for example how GNOME uses it.

Next steps:

  • List user stories that Redmine currently satisfies and try to find how it could work with GitLab.
  • Consider installing Redmine plugins that enable a GitLab-like workflow: free-form tagging (labels in GitLab-speak) instead of hard-coded custom fields / “blocks: core work XYZ: YYYYQN”, checklists (“task list” in GitLab-speak) instead of subtasks. This would allow some of our teams to experiment with this workflow.
  • Wait a bit. Moving won’t happen in 2018 anyway and it would be good to see how GitLab fares for other projects like GNOME and Debian (although Debian won’t use issue tracking).

Ressources:

Blueprint: https://tails.boum.org/blueprint/GitLab/

Parent Task: #15878

Related issues

Original created by @intrigeri on 15186 (Redmine)

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information