MK> Reporting code problems is more difficult. Yes, if it's a system MK> call bug raise a bug at the kernel.org bugzilla, and if it's a glibc MK> bug, then raise a bug at sourceware.org.
So perhaps on pages of section 2 of the manual, paste the system call address as where to report _code_ problem, and section 3, the sourceware.org address. If indeed those are still the right sections like they were back in '82. MK> But those paths often *won't* gain quick traction, since what is MK> really required is to CC relevant individuals on the report. And MK> finding those individuals requires some effort -- e.g., looking MK> for names in the source, or looking in the VCS to see who touched MK> the relevant source files. In the man pages, I can't practically MK> identify those individuals for each documented interface. MK> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ MK> man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html MK> Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html ^_documentation_ Anyway, just a Debian now has public relations officers etc. You/We've got to think of this from the Customer Relations perspective, even though nobody's getting paid. Anyway, compare a coreutils page with a full bug address, and a Linux page, which is more like a dollar bill, with no address for problems, like "if you the user knew what you were doing, you would know what to do with bugs, so you might as well just turn off the computer now." Anyway, so now the pages will say for documentation bugs do... begging the question "what about for other bugs, no just documentation bugs, which only account for 10%". OK, something to think about. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
