linux-kernel - Re: Documentation of kernel messages (Summary)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707121335.55817.rob@landley.net>
Date:	Thu, 12 Jul 2007 13:35:54 -0400
From:	Rob Landley <rob@...dley.net>
To:	"Li Yang-r58472" <LeoLi@...escale.com>
Cc:	"Gerrit Huizenga" <gh@...ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Kunai, Takashi" <kunai@...ux-foundation.jp>,
	holzheu@...ux.vnet.ibm.com,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	lf_kernel_messages@...ux-foundation.org, mtk-manpages@....net,
	jack@...e.cz, randy.dunlap@...cle.com, gregkh@...e.de,
	pavel@....cz, tim.bird@...sony.com, arjan@...radead.org,
	sam@...nborg.org, jengelh@...putergmbh.de, joe@...ches.com,
	auke-jan.h.kok@...el.com, hansendc@...ibm.com, davem@...emloft.net,
	Valdis.Kletnieks@...edu, kenistoj@...ibm.com,
	schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
	linux-doc@...r.kernel.org
Subject: Re: Documentation of kernel messages (Summary)

On Thursday 12 July 2007 9:53:54 am Li Yang-r58472 wrote:
> > Fielding patches and questions sounds like plenty to me...)
>
> I do think the documentation translation is very necessary even when
> there is a language maintainer, especially for the policy documents as
> HOWTO, codestyle , and etc.  The contributors should go through these
> policies and check their code for compliance before going to the
> language maintainer for help, or there will be too much for the language
> maintainer to translate.  The language maintainer doesn't need to
> translate all the documents himself, but he can help to coordinate the
> translation effort and help to make it update to date.

It would help if all the policy documents got grouped into a single 
Documentation/development directory so we could separate "policy documents in 
each language would be nice" from "that document about the amiga zorro bus 
really needs to be kept up-to-date in Navajo and that should be in the kernel 
tarball please".

Lemme see, which ones are we talking about?  The candidates are:
  applying-patches.txt
  BUG-HUNTING
  Changes
  CodingStyle
  debugging-modules.txt
  feature-removal-schedule.txt
  HOWTO
  kernel-docs.txt
  language-maintainers.txt
  ManagementStyle
  oops-tracing.txt
  SecurityBugs
  sparse.txt
  stable_api_nonsense.txt
  stable_kernel_rules.txt
  SubmitChecklist
  SubmittingDrivers
  SubmittingPatches
  volatile-considered-harmful.txt

That's everything I noticed in the top level directory that's a good candidate 
to be grouped into a "development" subdirectory.  Did I miss anything?

I note that Changes is a bit stale in places (16 bit assembly?), 
feature-removal-schedule.txt changes often but is good to know, 
kernel-docs.txt might be useless to translate considering it's mostly links 
to english documentation, language-maintainers.txt is assuming my patch from 
earlier today gets accepted...

I can submit a patch grouping all that stuff together into a subdirectory if 
it would help...

> If we do need a contact person, I can do it.  However I don't think
> there will be much translation work to do here.  As I stated before,
> most Chinese programmers are more or less capable of read/write
> technical English.  The difficult part is to let them know the benefit
> of merging code in kernel and teach them how to do it.  That's why the
> policy documents in native language will be very useful.

Does the above look like a good list?  There are more that need to be written, 
but that's what I saw in Documentation...

Rob

P.S.  Dear kmail/postfix developers: having a transient DNS lookup failure on 
one address in a long cc: list is _NOT_ a reason to have the message stay in 
the kmail outbox.  It should go into the postfix send queue and be retried 
from there.  Right now, if I tell it to resend, how do I know who it has and 
hasn't been successfully distributed to on the first attempt?  I've gotten 
dinged for trimming the cc: list before, but now I'm about to send out 
duplicates.  Wheee...
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/