GitLab consultation/Discussion summary

From mediawiki.org

The working group has seen a lot of input shared on the Talk page. People brought up many questions and potential concerns. This was expected as most of the participants are not familiar with Gitlab. In response fellow participants and the working group found answers to these questions and concerns.

TLDR:[edit]

  • The overall sentiment was mostly neutral with serious and discerning discussion
  • Participants are enthusiastic about better UI and UX options and more integrated features
  • Participants are positive about potential learning curve improvements for newcomers
  • Participants are positive regarding the review features
  • Participants have concerns about the impact of moving to a PR/MR methodology
  • Participants have concerns about the disruption that a switch causes

We are very grateful for this engagement and we have distilled a summary of the points mentioned. Please be aware that we cannot reproduce every single point made in the discussion in this document as it is supposed to be a summary. Many points have been grouped and some are so complex that you really should be reading the discussion itself.

We do not list all answers to the questions identified by the Working Group, but answers to many of these questions can be found in the other materials that the Working Group has prepared.

After the discussion ended the Working Group labeled the comments as one of 3 types: positive, negative, or neutral. Based on the 274 comments, 65 were positive, 68 were negative, and 141 were neutral.


The format of this summary is:

Topic

  • Points discussed
    • Subpoints and/or rebukes

Risks/costs of change[edit]

  • Productivity of some developers would decrease temporarily as we learn and adapt
  • Some specific workflows might get harder even in the long term
  • Short term harm is inevitable, but we should do this for long term benefit
  • This is gonna take a lot of (expensive) effort to switch
    • What we do now is also expensive and includes a lot of reinventing of wheels
  • If we don’t switch we should invest more in Gerrit to fix some of the identified problems.

Learning curve[edit]

  • Gerrit has a high learning curve because its model is rather unique and many developers are not familiar with it
    • This creates a high onboarding cost for both volunteers and new employees
    • git-review tooling is not tooling newcomers are familiar with
  • Ratify the de facto migration away from Gerrit, which is already underway
  • Some users feel that MR/PR model is confusing/bad
  • GitLab fork and merge model is a de facto industry standard
  • Wikimedia/MediaWiki is special, but not that special at the same time

Migration[edit]

  • What would happen to unmerged Gerrit patches?
  • Will we shut down Gerrit?  Risk of breaking links, etc
  • Gerrit review data is available in-repo.
  • Define a time period for migration, long term archive of Gerrit for reference.

See also roadmap

Non-free[edit]

  • GitLab is an Open Source product primarily developed by a company with a commercial focus.
    • We have been burned before with something like HHVM
    • GitLab has put a lot of effort in their Open source activities.
    • GitLab is widely used by other FOSS / free knowledge projects and if GitLab leaves open source, we won’t be the only ones affected
    • We will use the free and open source community edition (CE)
    • Long term viability https://www.mediawiki.org/wiki/Topic:Vv00jhxc6wav32mi
      • Gerrit is primarily developed (almost 100%) by Google for Google uses
      • GitLab is a product where the company behind it has a vested interest in more users using it (either CE or EE).
  • GitLab provides integrations with non-free services even in CE and these cannot be disabled
  • Were alternatives considered?
    • Not for this process, but in the past alternatives did not stack up.
  • Why NOT go for the commercial offering of Gitlab?
    • That way we could get all the benefits of the fully integrated solution
    • Cost
    • Open source is still preferred

reCAPTCHA[edit]

  • GitLab relies on the non-free reCAPTCHA
    • Account creation will not require captcha
    • We won’t really need it, and it is not enabled by default
    • We are not going to use reCAPTCHA

UX[edit]

  • Almost all functionality of GitLab is available through easy web interactions which are pleasing, with an inviting interface and thought out workflow
  • Avatars, user profiles (example)
  • Improved file render support (Markdown etc, but also Jupyter notebooks)
  • Better WebIDE
  • Easier to read and search code
    • Multi repository search is only available in EE
  • Review conversations are better than gerrit review
    • Supports screenshots
    • Emotes/reactions, etc.
    • Can edit and delete comments
    • Not everyone thinks this is better than Gerrit.
  • Gerrit v3 has become a lot better, we should give it a chance
  • GitLab’s mobile interface is pretty good
  • Webhooks, keys, deploy tokens, audit log etc etc also easily available

Self-control[edit]

  • Easy to make new projects and personal forks
    • Is this really an issue?  Yes.
    • Partially of our own making because we restricted project creation in Gerrit, but per-user project namespaces and easy forking are not part of Gerrit’s fundamental model.
  • GitLab pages would be cool
  • Jupyter notebook support would be cool
  • GitLab CI integration
  • But how do we keep all of that under control?

Reviews[edit]

  • Are we trying to solve the wrong problem? Aren’t our problems with code review social / organizational rather than technical / with the tooling?
    • Working group position: Social concerns are valid, but this consultation is focused on tooling, which is a pressing issue in its own right.
  • MR/PR vs Gerrit model
  • Squash merge
  • Gating merges on review
  • Cross repository merge dependencies
    • There is a feature for this, but not in CE
  • Tyler’s summary:

See workflow pages

Continuous Integration[edit]

  • Don’t we already have self-service CI?
    • No. Setting up a new project is cumbersome even for experts, and few people can actually do it.
  • Under GitLab CI, would we test only the head of a branch? Is there a risk of commits on the main branch which don’t pass tests?

Security[edit]

  • Can GitLab deal with spam?
  • Gerrit doesn’t deal with spam either, most other instances are firewalled / do not allow open registration.
  • Can we block/ban users in GitLab?
    • Yes; there are abuse reports and a queue for managing them.
    • See: https://docs.gitlab.com/ee/user/admin_area/abuse_reports.html and https://docs.gitlab.com/ee/user/profile/account/delete_account.html
  • Will we use Wikimedia accounts for login?
    • Yes via LDAP
    • We’re the only large open Gerrit install using LDAP.

Input from other orgs / projects[edit]

  • Positive sentiment from contributors to Debian, KDE.
Retrieved from "https://www.mediawiki.org/w/index.php?title=GitLab_consultation/Discussion_summary&oldid=6391894"