How Red Hat uses GitLab for kernel development

Posted Oct 3, 2021 18:02 UTC (Sun) by marcH (subscriber, #57642)
Parent article: How Red Hat uses GitLab for kernel development

> A bigger issue, though, has to do with robustness. If kernel.org is not reachable, kernel development still goes on; an outage is inconvenient but not really a big problem. Adding a central forge, though, risks creating a situation where, should it go down, no work can get done.

>Perhaps the biggest concern, though, has to do with making GitLab into a single point of failure; what if the company is bought out by somebody who is hostile to Red Hat and its goals?

SPOF / centralization is the only real problem. All other issues are either fairly easy to solve or solved already (kudos to RedHat for trying to move things forward _and_ sharing their efforts)

So the next (and big!) step is to find some good distributed database model and implement a free software forge based on it. Funny enough that sounds very much like what Bitkeeper and then git achieved.

> In that case, it would be relatively easy to pull all of the necessary data out of the system; the Git trees are already mirrored elsewhere. They have a script now that can take all of the comments from GitLab and dump them into a public-inbox instance.

Sure but that would be a huge step back.

How Red Hat uses GitLab for kernel development

Posted Oct 7, 2021 12:22 UTC (Thu) by fung1 (subscriber, #144307) [Link] (4 responses)

> SPOF / centralization is the only real problem. All other issues are either fairly easy to solve or solved already (kudos to RedHat for trying to move things forward _and_ sharing their efforts)
>
> So the next (and big!) step is to find some good distributed database model and implement a free software forge based on it. Funny enough that sounds very much like what Bitkeeper and then git achieved.

As of a few years ago, Gerrit moved all comments and discussions into Git objects so they can be replicated and fetched along with the merged commits and proposed changes for a repository. They basically got rid of the RDBMS entirely, except for one UI-related feature for tracking which specific files you've already "seen" when reviewing a particular version of a patch (which has fairly ephemeral utility at best, and almost nobody I know relies on that behavior anyway).

Fossil

Posted Oct 21, 2021 22:36 UTC (Thu) by marcH (subscriber, #57642) [Link] (3 responses)

Interesting, thanks!

Also realized I forgot to mention Fossil:
https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-gi...
"One way to describe Fossil is that it is "GitHub-in-a-box."

That's probably because I never used it and also because I violently disagree with the lack of history rewriting:

> When every commit is pushed to the parent repo by default, it encourages a working style in which every commit is tested first. It encourages thinking before acting. We believe this is an inherently good thing.

Very ironic considering I use git rebase -i to _test_ a variety of "what if" scenarios every single day.

I find the rest of the page very impressive.

Fossil

Posted Oct 22, 2021 10:56 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

There's arguably two separate sets of workflows you want out of your SCM:

Immutable shared history, showing how the product developed. This is curated by the committers to tell a story about the code.
Mutable private history, where you're checkpointing your work in interesting places so that nothing of interest is lost when you try something out. You will later rebase and restack this to become the immutable shared history you push.

The ability to share the mutable history is useful in some cases, but to do it well adds a lot of complexity (see Mercurial's "Changeset Evolution" extension). But the ability to work locally and store up commits of random changes, then to build and test the final history you wish to push, is extremely useful.

Fossil

Posted Oct 22, 2021 20:56 UTC (Fri) by flussence (guest, #85566) [Link]

I'd liken it to the "preview comment" button here - that one roadbump causes me to put far more care into what I'm emitting than if there'd just been a single post button (even if it doesn't seem like it sometimes). I've used many other UIs for committing what I type to the internet, and it feels like there's a definite correlation between the overall quality of results in some of them and whether they let (or require) you experiment and make mistakes in private.

git "volatile" branches

Posted Oct 25, 2021 0:41 UTC (Mon) by marcH (subscriber, #57642) [Link]

> There's arguably two separate sets of workflows you want out of your SCM:
> ...
> The ability to share the mutable history is useful in some cases, ...

Yes it would save a lot of confusion if git provided some kind of "volatile" branch marker so publishers can share their intentions and set mutability expectations. Currently this is performed with poor branch naming conventions or worse: pure word of mouth.

Giving the distinction between 1. and 2. a name would elevate it and also clarify the recurring "don't rebase public branches" advice which is exactly what intel-next and others do all the time!? And hey, who knows it could even stop questions like "why can't I commit and push at the same time" from Fossil and other fans.

https://www.google.com/search?q=git+volatile+rebase+branches

How Red Hat uses GitLab for kernel development

Posted Oct 31, 2021 14:12 UTC (Sun) by misc (subscriber, #73730) [Link]

You might be interested in the Fedeproxy project ( https://fedeproxy.eu/ ) and the Forgefed project ( https://forgefed.peers.community/ )

While federation do not solve the issue of centralization (as we still need some reference point), it reduce the risks of SPOF, and by making forges interoperable, it would also limit problem if one turn bad.