Muting and unmuting threads (Was: Migrate away from vger to GitHub or (on-premise) GitLab?)

From: Dragan Simic <dsimic@manjaro.org>
Date: Feb 2, 2024, 11:23 UTC
Message-ID: <93be64af474b228e914a4c39443b5a9c@manjaro.org>
In-Reply-To: <c9a0cb1fe64f8e7d21c21458e5e76af9@manjaro.org>

Hello everyone,

I went ahead and contacted the mlmmj project, which runs the vger mailing lists, [1] with an idea to implement a new command/feature that allows threads to be muted or unmuted. For example, that would allow receiving only the replies to one's patch that was sent to a list.

The initial reactions are good, but various concerns have been raised regarding the actual implementation. I'll think about the way to implement it in an efficient and simple way. I think this would make using mailing lists much more friendly to many users.

All suggestions and thoughts are welcome, of course.

[1] https://people.kernel.org/monsieuricon/subspace-mailing-list-server

On 2024-02-02 11:54, Dragan Simic wrote:

Show 49 quoted lines

> 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.