[procps] Re: backporting
- From: Sami Kerola <kerolasa@xxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Sat, 17 Dec 2011 20:13:58 +0100
On Wed, Dec 7, 2011 at 12:21, Jim Warner <james.warner@xxxxxxxxxxx> wrote:
Hi Jim,
> Additionally, breaking 'headers' into individual words practically
> guarantees the translation will result in ugly, misaligned output.
> Those are the very strings that need not only context but some
> 'Translation' notes as well. Except for top, no other program
> provides any translator guidance whatsoever.
I hope this change fixes most of the header issues.
https://gitorious.org/~kerolasa/procps/sami-procps-ng/commit/4a05fd327bc0c1dec93c32c1d961a2494e570acc
The true test what in NLS works is still to come; the translation
test.
> Before we go much further, I think we should try to reach agreement
> on some general approaches/objectives. I will argue against using
> those headers you borrowed (without attribution) from util_linux.
> In some cases they needlessly reinvent an existing wheel and in
> others they obscure/complicate the maintenance effort. I'd be very
> interested in your arguments for their use.
The libproc-ng should not contain project private functions, such as
xmalloc. My reasons are;
1. Libproc-ng is distributed 'users of the internet' and it should
not contain other than /proc or /sys file system related functions.
For example xmalloc should not be part of what that library provides.
2. Common & generic functions, such as xmalloc, can and will clash
with private functions in other projects. That means the libproc-ng
interface should be as clean as possible.
3. Library private functions (local: section in proc/library.map)
cannot be called from program code. As there needs to be some way to
call xmalloc having the function in project 'code library' is good
enough equivivelant.
4. Is there a better way to do the same?
> In any case, to keep the nls ball rolling I'd like to incorporate
> the attached top patch in your nls branch.
Don't you really care that for example...
vmstat -p /dev/sda1
...does not work? IMHO the backport patches sould be either merged to
upstream, or explained one by one why the change can be ignored.
Notice that I don't feel motivated to conflict fix nls branch before
the backport branch is dealt.
--
Sami Kerola
http://www.iki.fi/kerolasa/
Other related posts:
