Not a man-pages bug. And, why not just send a patch to the person/list concerned for this trivial fix?

1) There is only a vague mention of a list at the bottom of that page. No mention of a person.
2) If I send a message to that list will the problem will get solved, or might it drop through the cracks and get ignored maybe.
3) Please reassign this bug to the correct component.

Dan,

(In reply to Dan Jacobson from comment #2)
> 1) There is only a vague mention of a list at the bottom of that page. No
> mention of a person.

Did you look in MAINTAINERS?

DOCUMENTATION
M:      Jonathan Corbet <corbet@lwn.net>
L:      linux-doc@vger.kernel.org
S:      Maintained
F:      Documentation/
X:      Documentation/ABI/
X:      Documentation/devicetree/
X:      Documentation/acpi
X:      Documentation/power
X:      Documentation/spi
T:      git git://git.lwn.net/linux-2.6.git docs-next


> 2) If I send a message to that list will the problem will get solved, or
> might it drop through the cracks and get ignored maybe.

Did you try?

> 3) Please reassign this bug to the correct component.

Who says there is a correct component? Not every kernel component makes use Bugzilla.

In any case, raising reports for trivial problems like this really is a waste of everyone's time. Please don't do it. Do some minimal research (see "1)") to find the best path for solving the problem and send a patch.

Thanks,

Michael

All I am trying to say is that you need a general bug tracker for such
problems. People will not know that they are supposed to look in various
files to find various names. And indeed posting to that list often meets
with no answer. So do consider a Debian-like policy, where one can
always still post to their bug-tracker, no matter what.

(In reply to Dan Jacobson from comment #4)
> All I am trying to say is that you need a general bug tracker for such
> problems. People will not know that they are supposed to look in various
> files to find various names. And indeed posting to that list often meets
> with no answer. So do consider a Debian-like policy, where one can
> always still post to their bug-tracker, no matter what.

The kernel community is heterogeneous in this respect--some use the bug tracker, some don't. There is no global (ly enforced) policy. BTSs are of course not a panacea. I know from my own experience with Debisn that man pages bug reports sometimes sit there for *years* unattended, sometimes even for years after I add a note saying the problem is fixed upstream.

The general problem I think is this: Bug Trackers facilitate throwing a problem to someone else, rather than rolling up your sleeves and getting involved in the fixing yourself. Yes, we need bug reporters, but the problem is there aren't enough bug *fixers*. And I think bug reports like this illustrate the problem quite well. You may say that mails to that list are sometimes ignored, and I won't disagree, but I think if you sent a well formatted patch to the list, it'd likely be attended to. For my part, with respect to man-pages, I explicitly request[1] that people don't use Bugzilla for this kind of report.

Thanks,

Michael

[1] https://www.kernel.org/doc/man-pages/reporting_bugs.html

Indeed recently some of my 12 year old Debian bugs got fixed.

Here in Taiwan several cities have set up catch-all one stop toll-free
numbers for any problem.

Even though a free software project in contrast makes no promise the
bugs will ever get fixed, but at least having somewhere to put them is
better than having nowhere. Also at least the user will do some minimal
categorization when entering the bug. Or at least try.

Anyway back to my city example, I think getting citizens to report
problems at all is much more valuable than trying to train them about
which department to hopefully contact like back in the old days.

Anyway for all organizations, if a user gets the message that little
reports are unwelcome, well you are not going to get big reports either.

OK I won't report anymore bugs.