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

[Dragan Simic <dsimic@manjaro.org>]

On 2024-02-02 11:18, Hans Meiser wrote:
>> 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.
> 
> Sure. Eventually, I'd rather propose to have parts of the man pages be
> generated from code comments (XmlDoc, JsDoc or similar), particularly
> syntax and parameter list. That would keep documentation from
> deviating from code right from the beginning. And it would keep
> documentation writers from manually updating obvious parts.

That might work out in some places, but I'm not really sure about the
overall effectiveness.  The git man pages don't document function calls.

>> A git server?  I was under impression that you proposed running an
>> own instance of GitLab or something similar.
> 
> Basically, GitLab, GitHub, Azure DevOps are all just Git servers, plus
> collaboration and automation functionality. I suggested using GitWeb
> only in case you wanted to write  (and keep control over)
> collaboration and automation functionality yourself. Otherwise you may
> use one of the existing ones that have already been written (i.e.,
> GitLab, GitHub, Azure DevOps).

The plus brings additional issues.  It's been already noted that 
favoring
any of those solutions actually wouldn't be in the interest of git 
itself
as a project, because it wants to remain neutral.

IMHO, these days too much is expected to be handled by "something else",
instead of the developers handling that.  It's like offloading the 
basically
unavoidable complexity to some utility, and expecting that the 
complexity
will somehow go away.

In other words, a developer has to keep quite a lot in their short-term
memory, and a lot in their long-term memory, to be able to accomplish 
some
task, and hardly any utility is going to make that significantly easier.
The same principle, in general, applies to a group of developers working
on the same task.