Topic on Talk:GitLab/2020 consultation

There's a point I've argued in conversation that I'm not sure has been articulated explicitly as part of this consultation, so I'll do my best to lay it out here.

Briefly: It seems likely to me that we're getting the PR/MR model whether we want it or not. My thinking is as follows:

• The current status quo is not that everything lives on Gerrit. Per the "Why" section, it's Gerrit plus 150-odd repos on GitHub.
• If we didn't have a requirement that things deployed to production be hosted on Gerrit, the GitHub number would almost certainly be higher.
• If we don't provide standard code review & CI tooling that meets some basic expectations, projects and teams will continue drifting to other platforms.
• Eventually, we're going to reach a crisis point with Gerrit. It'll be brought to us by one or more of:
  • Our ability to maintain a public Gerrit instance (already stretched to the breaking point in terms of people and resources)
  • The upstream health / responsiveness of Gerrit as a project
  • Pressure from developers and projects/teams to ratify the de facto migration away from Gerrit which is already underway

And at that point, my expectation is that we're going to wind up scrambling to adapt, locked into a fully-proprietary monopoly platform (GitHub) with little control over the decision, and cleaning up a few years' worth of additional fragmentation. We'd still be adapting to PR-style workflows and tooling, just less deliberately, not on our own terms, and at a greater remove from the path taken by other projects that share a great many of our values and concerns.

In thinking this through, it's also become clear that if we elect not to migrate away from Gerrit at this time, we're still going to have to spend substantial money and person-hours on the technical problems of our code review infrastructure. There's just not a viable option to do nothing here. (I specify "technical problems" because this consultation is first and foremost about improving an unsustainable software situation, not about whether our culture and priorities around code review need help. The latter is a very important question, but it is not the problem we set out to solve with this process.)

In addition to the 152 GitHub projects you mention there are several additional GitHub organizations that contain repositories used in people's day-to-day. Not to mention the tools that exist under individual user accounts that folks are using for day-to-day work.

Many repos are created outside Gerrit because it's easier to create them elsewhere. Or easier to set them up elsewhere. Or easier to access them elsewhere. I, personally, don't put small projects on Gerrit because I don't want to think about where they fit in the giant hierarchy of things in Gerrit before I can even start on a README.

I am a Gerrit workflow fan, but I worry that if we don't address the real issues with Gerrit that we'll just end up slouching into whatever's easiest without regard for guiding principals or preserving workflows or CI or deployment or anything other than what's expedient.

I'm slowly coming to the same realization, if for different reasons. We discovered that force-pushing to a branch leaves no record of the previous history. This is a dangerous situation because an accidental push could irreversibly destroy work and break auditing. If the branch is associated with a merge request however, the patchset comparison tools become available. We very much would want to use this workflow, since most of us have been conditioned by years of force pushing and I expect that we'll find ourselves continuing to do so.

> Pressure from developers and projects/teams to ratify the de facto migration away from Gerrit which is already underway

Isn't this a social issue, in that teams are largely free to pick whatever code review platform they like to do their work -- similar to how different teams used different chat mediums, or I think in the not too distant past there were various combinations of Asana / Trello and perhaps other bug trackers in use by team. Similar to how in theory everyone is supposed to use phabricator to organize and document their work, there should probably be a similar effort to have people use the same code review tooling. Otherwise I could easily see, of all those repositories listed as being used on GitHub, the majority staying on GitHub since GitHub !== GitLab.

> Our ability to maintain a public Gerrit instance (already stretched to the breaking point in terms of people and resources)

My understanding is that GitLab is more complex to host and maintain, would it require fewer resources?