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

From: Michal Suchánek <msuchanek@suse.de>
Date: Feb 2, 2024, 11:50 UTC
Message-ID: <20240202115004.GV9696@kitsune.suse.cz>
In-Reply-To: <0e3e6102-40eb-4462-b541-0c7452e79f42@gmail.com>

Hello,

On Fri, Feb 02, 2024 at 11:15:26AM +0000, Phillip Wood wrote:

Show 28 quoted lines

> On 02/02/2024 05:10, Patrick Steinhardt wrote:
> > On Fri, Feb 02, 2024 at 01:44:03AM +0000, brian m. carlson wrote:
> > > On 2024-02-01 at 18:36:48, Hans Meiser wrote:
> > [snip]
> > > > In the end, it's all just about git. You may create your own git
> > > > webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),
> > > > or just use an existing one, like the GitLab server:
> > > > https://about.gitlab.com/install/
> > > 
> > > The Git project has tried for a long time to be neutral on any
> > > particular external piece of software.  Installing a GitLab server as
> > > our preferred development platform would promote GitLab as the preferred
> > > forge to other users.  Similarly, moving to GitHub would prefer GitHub
> > > over other forges.  That's not a thing we want to do.
> > > 
> > > We also don't accept patches or features for the benefit of one
> > > particular forge or external project.  Patches and features must be
> > > of general benefit to the project at large.
> > 
> > I think this point is indeed really important in the context of the Git
> > project.
> 
> Agreed, thank you for making it brian. If we did decide to use a forge we'd
> need to be very clear in our decision making that it was selected based on
> the specific needs of this project and was not a general endorsement of one
> product over another. We'd also need to address the important practical
> problems of finding resources to maintain the infrastructure and software to
> run it.

In this context using lore is basically also a forge choice. It is built on top of git, and expands the functionality of what the project git repository alone provides.

Unlike most other forge software it is based completely on open standards such as e-mail headers and git itself, very open and modular, and does not in any way tie the project git repository to this additional functionality provided by lore.

This open and separate nature of lore is what makes it the tool of choice for Linux and git, and any forge that aims to replace lore should aim at similar level of openness. Of the forges I am aware of only sourcehut comes close in terms of planned functionality but it's nowhere near completed as far as I am aware.

Given the open nature of lore it should be feasible to provide additional interfaces on top of it that cater to people used to PRs on popular forge web UIs without hijacking the whole project and the existing tools and interfaces. For some reason people are set on replacing it as a whole, and removing the interfaces they personally don't use, calling them obosolete.

In a project with large numger of collaborators with varying backgrounds that's not going to work well. There are many people working on git using different workflows, and adding support for new workflow by removing a number of existing ones will cause problems. The goal of changing the forge software should be to be more open, supporting more users with more varying workflows and needs, not less.

Thanks

Michal