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