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

[<rsbecker@nexbridge.com>]

On Thursday, February 1, 2024 2:00 PM, Dragan Simic wrote:
>On 2024-02-01 19:36, Hans Meiser wrote:
>>> Could you, please, clarify what kind of git documentation are you
>>> referring to?  Are you having git man pages in mind?
>>
>> Yes, these in particular.
>>
>> From my point of view, many of these are quite unorganized, hard to
>> read and – as I believe – need a fix-up. Markdown could replace the
>> currently used language, so editing them would be more easy, proving
>> support for preview and lint the documentation.
>
>Please keep in mind that editing the git man pages requires very intimate knowledge
>of the related git source code.  Many times even small changes to the language style
>can change the meaning and diverge the man pages from the source code, making
>the man pages useless.
>
>>> Quite frankly, I think you've missed some important points from the
>>> Konstantin's message.  To sum it up a bit, not having continuous
>>> support is simply unacceptable for any kind of a long-term project.
>>
>> As I wrote, once installed on-premise, no-one will shut down an
>> on-premise git server except for yourself. It can run for eternity.
>> You just need someone to administer it properly and publish the
>> website.
>
>A git server?  I was under impression that you proposed running an own instance of
>GitLab or something similar.

Git is unique, as a project, given that everything (! Not everything but a whole lot) is managed using git, including the enterprise git server platforms.

A huge advantage of using a git server is being able to mirror the repository. If we went with a GitLab host, we could potentially mirror over to GitHub. The drawback is that the pull request history (and related discussions) id not (currently) preserved. I think this is a situation no matter what, even if we go GitLab/GitLab or GitHub/GitHub. The value of the discussion threads is the most important part of what needs to be preserved. I have high confidence that the team could move to either Pull Request/Merge Request structure reasonably easily, but if we had to move again in future (count on it), there must be a way to preserve the community assets of the discussions that went into making decisions. Without that, I am concerned that a migration to a GitLab (or any other) instance would increase velocity but put long term decisions at risk.

>> 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/
>>
>> In these servers, everything is configurable. Moreover, many plug-ins
>> exist for plumbing extensions to these providers. It's possible to
>> establish your own workflow, rights management and automatic handling.
>> You just need someone who is an expert with the tool of your choice.
>>
>> Many other great repositories already are using one of those
>> providers; Meta, Google, Microsoft for example share their code there
>> – just to name a few. I wouldn't consider these users as being known
>> for being exceptional risk-takers.

--Randall