[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160413124622.584ff77e@lwn.net>
Date: Wed, 13 Apr 2016 12:46:22 -0600
From: Jonathan Corbet <corbet@....net>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: SeongJae Park <sj38.park@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
jiangshanlai@...il.com, dipankar@...ibm.com,
mathieu.desnoyers@...icios.com, josh@...htriplett.org,
tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
David Howells <dhowells@...hat.com>, edumazet@...gle.com,
dvhart@...ux.intel.com, fweisbec@...il.com, oleg@...hat.com,
bobby.prani@...il.com, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean
translation
On Wed, 13 Apr 2016 05:49:53 -0700
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> We currently do
> not have a good way to tell which translations are no longer keeping up
> and thus need to be pruned, and we would need one.
So I have to play the devil's advocate a bit here... we don't currently
have a mechanism to tell us which files in Documentation/ in general are
not keeping up and needing to be pruned[0]. But we don't use that as a
reason to block documentation submissions in general.
It's a bit harder for a random passer-by to determine that a translation is
out of sync[1], but we do have a version control system that can help us to
see that, at least, somebody is occasionally updating things. It's not a
complete black box.
I would argue in favor of including translations when somebody has taken
the time to create them. They cost little and can be helpful for
developers who are struggling with both the kernel code and the English
language.
jon
[0] OK, a real devil's advocate would say that "ls" or even
"echo Documentation/*" is sufficient.
[1] Though, perhaps, many or most developers can make just as much
sense of a version of memory-barriers.txt in a language they don't
understand as they can with the original. :)
Powered by blists - more mailing lists