[Asterisk-code-review] progdocs: Fix grouping for latest Doxygen. (asterisk[master])

[Alexander Traud]

Attention is currently required from: Kevin Harwell.
Alexander Traud has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/17334 )

Change subject: progdocs: Fix grouping for latest Doxygen.
......................................................................


Patch Set 2:

(1 comment)

Patchset:

PS2: 
> I don't see the harm in minor breakages to that opinion.

You gave a minus one. You gave a direct order. Consequently, the change is somehow blocked for a valid reason. I have then to resolve that either by arguing or following the order. There was once a Wiki that stated, as a contributor, I am not allowed to argue. I do not find that any more. Anyway, that behavior further burdens me because I have to find a way to get rid of that -1, although my change was totally valid. Even checking (and stating) whether I am unwilling or unable takes additional effort to come to that conclusion. Especially ‘unable’ is problematic in public. Even for me, after so many commits, changing a commit in review is a daunting task (perhaps I still misuse Gerrit). Others might not be able at all. Especially when the change is not a simple cherry-pick over all branches but different in some branches. Therefore, even such minor breaks can have a disastrous outcome. In any case, it makes it more complicated for me, someone who might not benefit from the change in the first place.

Finally, you cannot check whether the other one understood and double-checked your order, or blindly followed it. Consequently, you have the problem of a transitive +1.

Another example: With my very first commit in the Asterisk project, I got a -1 because I copied a log message statement from code around me. That did not use ast_verbose, ast_debug, ast_log. At that time, I did not even know about those symbols, I simply copied over the behavior around that code. I then had to learn and understand why I got a -1. Even that I did not get. And then learn that logger stuff. And then I had even to change another code line because I touched it semantically (the indention of that line of code changed because of my change). All this increases the burden on the contributor.

Consequently, I suggest staying away even from minor breakages. If you want to avoid an additional change on your behalf, why not just suggest it (not order it) and give a +/-0 (not a -1), so original change is not blocked, and the contributor is not *obligated* to respond.

Another example: I found this particular group-command issue in 650 projects in Debian. In 650. If 1 of 100 take minor breakage, this turns into around the effort same as 657 projects. No problem. If 10 of 100 take minor breakage, this gets roughly the effort of 715 projects. Perhaps I have simply not the time even explain to 65 projects, I am not willing to do that. In other words, what you think is minor, might accumulate to a really big one for the other party.



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/17334
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Change-Id: I4687857b9d56e6f44fd440b73af156691660202e
Gerrit-Change-Number: 17334
Gerrit-PatchSet: 2
Gerrit-Owner: Alexander Traud <pabstraud at compuserve.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Kevin Harwell <kharwell at digium.com>
Gerrit-Attention: Kevin Harwell <kharwell at digium.com>
Gerrit-Comment-Date: Tue, 30 Nov 2021 10:22:11 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Sean Bright <sean at seanbright.com>
Comment-In-Reply-To: Kevin Harwell <kharwell at digium.com>
Comment-In-Reply-To: Alexander Traud <pabstraud at compuserve.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20211130/b5fdd9ff/attachment-0001.html>