Re: Migrate away from vger to GitHub or (on-premise) GitLab?

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Thu, Feb 01, 2024 at 12:10:11PM +0000, Hans Meiser wrote:
> is there any current discussion about moving Git development away from using
> a mailing list to some modern form of collaboration?
> 
> I'd like to be able to follow a structured discussion in issues and to
> contribute to the Git documentation, but the mailing list currently just
> bloats my personal inbox with loads of uninteresting e-mails in an
> unstructured waterfall of messy discussion that I am not able to follow
> professionally.

Here's a perspective from the world of Linux kernel, where this discussion is
continuously raging. Funny enough, the main objection a lot of kernel
maintainers have to forges is that it makes it really hard to find relevant
discussions once the volume goes above a certain threshold. These folks have
become *extremely* efficient at querying and filtering the mailing list
traffic, to the point where all they ever see are just those discussions
relevant to their work. They love the fact that it all arrives into the same
place (their inbox) without having to go and click on various websites, each
with their own login information, UI, and preferred workflow.

The kernel maintainers are able to review tens of thousands of patches monthly
with only about a hundred or so top maintainers. To them, this system is
working great, especially now that some tools allow easy ways to query,
retrieve, verify, and apply patches (shameless plug for lore, lei, and b4
here).

The obvious problem, of course, is that these folks are FOSS's "marathon
runners" who got really good at their workflow, but the situation is different
for anyone else who is just starting out. Any new kernel maintainer stepping
up obviously finds this overwhelming, because they aren't yet so good at
filtering the huge volume of the mailing list traffic and to them it's just a
torrent of mostly irrelevant patches.

> Are you consideration for migrating?

Yes, of course, this is constantly under consideration. There isn't some sort
of anti-forge cabal that is preventing things from going forward, but there
are some serious hurdles and considerations to consider:

- How to avoid a vendor lock-in? Those of us who have been around for a while
  have seen forges bloom, and then shrink into irrelevance (e.g. bitkeeper)
  or slowly ensh*ttify to the point of unusability (sourceforge). GitHub is a
  proprietary service owned by a single company who are currently
  FOSS-friendly, but have certainly been extremely FOSS-hostile in the past.
  GitLab is open-core, and the current record for open-core projects isn't
  very encouraging (Puppet open-cored themselves into irrelevance, Terraform
  has gone full-proprietary, among most recent examples). Full-FOSS
  alternatives exist, but people aren't really that enthused about using
  less-popular solutions like Forgejo, because they hate unfamiliar UIs almost
  as much, or even more than they hate unfiltered mailing lists.

- How to avoid centralization and single points of failure? If Linux or Git
  move to a self-hosted forge, how do we ensure that an adversary can't stop
  all development on a project by knocking it offline for weeks? This has
  literally just happened to Sourcehut and Codeberg -- and as far as anyone
  can tell, the attacker was just bored and knocked them out just because they
  could. Yes, you can knock out vger, but this will only impact the mailing
  list -- people can still send around patches and hold discussions by
  temporarily moving to alternative hosts. With the distributed nature of the
  mailing list archives, this can even be largely transparent to anyone using
  lei-queries.

- How to avoid alienating these hundreds of key maintainers who are now
  extremely proficient at their query-based workflows? We're talking about an
  extremely finely-tuned engine that is performing remarkably well -- we don't
  want to disrupt development for months just to try things out with a forge
  and find that it isn't working out.

Finally, there's also the consideration of current trends. One upside of "AI"
(LLM, really) technologies is that they are extremely good at taking in a huge
source of data and finding relevant information based on natural language
queries. I can very easily see a mechanism spring up in the next year or less
where you can issue a query like "send me any threads about reftables or
promissory remotes if they contain follow-ups from Junio" and reasonaly expect
this to work and work great -- all while keeping things decentralized in
addition to distributed.

Above all, this isn't a "forges are terrible and shouldn't be used" response
-- they are clearly useful, especially when it comes to CI integrations. A
large part of my work is bridging forges with mailing lists and vice-versa,
which I hope I'll be able to do in the near future (GitGitGadget already does
it with GitHub, but my goal is to have a pluggable multi-forge solution). I
just wanted to highlight the aspects that aren't necessarily obvious or
visible from the outside.

Best regards,
-K