Re: A linux patch for a typo

[Lin Zhe Min <ljm@ljm.wownet.net>]

About this issue, I just have two suggestions.

I think the most important thing is that it is _necessary_ to establish a 
_uniform_ announcement to every kernel changes. (Sorry that, though "the 
less perfect the more liberty", I still think it ought to be.) After 
great evolutions of 2.1.xx kernels, kernel are mostly imcompatible to old 
softwares, esp. low level libraries, device drivers, and low level 
application programmes (e.g., cdwrite). However I have never seen an 
official announcement in linux-kernel list or some hit places. Only in
hard-to-read Changes are they written.

To newer programmes, I think it is easy to go for such kind of backward 
compatibilities to kernel changes with GNU autoconf (if it is supported
in later versions). To old programmes which do not know new kernel 
structures, I think their authours or maintainers can decide whether they 
want to follow kernel steps or not, in condition of the uniformed 
announcements (or better called `specification-update'?) are done, by 
which all system programme authors can be noticed and then react. I 
suppose this kind of announcement can be done in linux-kernel list, or
(if possible) in another list (linux-kernel-announce?), or even at a
web site or in a well formatted file accompanying kernel distributions 
for historical trace. The new list (if there is one) should contain in the 
beggining every authours registered in LSM catalog.

A second suggestion is that there would better be a decree (or something 
like that) between kernel maintainers and LIBC maintainers, which is to 
be generated after several conferences (at least one, participated by 
every maintainers, by IRC is suggested). I don't think it is a good idea 
for these two domains of maintainers to have gaps or (on the list) 
illness to one another. I support that Linus modify several buggy (or,
ugly) structural imprefect, however, that LIBC maintainers keep including 
kernel headers and structures as well. IMHO, there must be some rules. I
agree what Mr. Guilmette said. The idea of any version of LIBC works on
any version of kernel, or vice versa, is inpractice. The situation of
one particular version of kernel working on one specified version of LIBC 
would never take place (or both Linus and LIBC maintainers will be tired 
to death. <Joke>) Everyone knows there is a internal limit.

I would appreciate, if possible, both part of staffs could think of my 
opinion. That might be a step to a new age.


.e'osai ko sarji la lojban.	==> Please support the logical language.
co'o mi'e lindjy,min.		==> Goodbye, I'm Lin Zhe Min.
Fingerprint20 = CE32 D237 02C0 FE31 FEA9  B858 DE8F AE2D D810 F2D9