Re: Configure.help i18n system

Re: Configure.help i18n system

[Andries.Brouwer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

> I wonder if the Configure.help text should not possibly be even _more_
> distributed than just splitting it up into different files. It might very
> well be acceptable to actually distribute it over the net (and have just
> a mapping of config options into www-addresses or something).

I think this is a bad idea.

(i) The kernel has high visibility, and work on the kernel
[even if only on the Documentation subdirectory] has high "prestige".
As a consequence, parts of the kernel tree are kept much better
up-to-date than documentation found elsewhere.

(I have been trying for years to find people willing to do something
to the very outdated ioctl_list.2 or proc.5 or bootparam.7.)

When distributed, very quickly Configure.help would be outdated,
and of very uneven format and quality.

(ii) So far, building a kernel involved getting a single tarball.
If the help for over a thousand configuration options is found
a hundred different places on the net, of which five are currently
unreachable, things get really cumbersome.

The current system is not so bad.

Andries

Re: Configure.help i18n system

[Francois Romieu]

Andries.Brouwer@cwi.nl <Andries.Brouwer@cwi.nl> ecrit :
[...]
> (i) The kernel has high visibility, and work on the kernel
> [even if only on the Documentation subdirectory] has high "prestige".
> As a consequence, parts of the kernel tree are kept much better
> up-to-date than documentation found elsewhere.

Why would quality be lowered if instead of trying and push a Configure.help 
patch to an already busy Linus, one should notify the maintainer ?
Simply because it doesn't gain the same "prestige" to the author ?
*big pain*

I don't forget your proc.5/bootparam.7 argument but it's not the same
point imho.

[...]
> (ii) So far, building a kernel involved getting a single tarball.
> If the help for over a thousand configuration options is found
> a hundred different places on the net, of which five are currently
> unreachable, things get really cumbersome.

Not everybody reads a thousand configuration options entry.
If I want a kernel tailored for a specific machine, I keep a .config
somewhere, make oldconfig and so on. I don't read a Configure.help
entry that hasn't changed for months. Documentation/Changes is enough.
If I want to build the usual "does everything compile?" kernel, the
Configure.help entry isn't that needed.
If it's the first time I compile a kernel, $DISTRIBUTION could include 
the extra package somewhere. Outdated ? We aren't talking about people 
working with testing versions thus I doubt it's really a problem.

> The current system is not so bad.

Yes. However, the point of "Configure.help doesn't belong to core"
makes sense (as long as it doesn't prevent compile).

--
Ueimor

Re: Configure.help i18n system

[Linus Torvalds]

[ Kernel mailing list added to Cc ]

On Thu, 7 Jun 2001, Keitaro Yosimura wrote:
> 
> Configure.help i18n system is the thing which uses MD5 SUM of the text
> of the text as a key, and calls suitable data to the present language
> setup (it judges from an environment variable).

Quite frankly, I dislike the current Configure.help setup for a lot of
reasons, none of which are i18n-related.

One is a "simple" technical detail (the fact that it is all in one big
file instead of distributed over the places that actually _implement_ the
different config options), but the other is just that from what I've seen,
the overlap between people developing the code, and the people trying to
explain the config options is actually rather small.

So I wonder if the Configure.help text should not possibly be even _more_
distributed than just splitting it up into different files. It might very
well be acceptable to actually distribute it over the net (and have just a
mapping of config options into www-addresses or something).

I suspect that this is actually something that intersects with the i18n
work: how does the i18n projects distribute the actual help texts? Done
right, maybe the same distributed environment could be used for
everything, and getting Configure.help entirely out of the "core kernel"
tree, and into a separate distribution (where the English version would be
just one among many distributions).

I like to keep things that belong together in one distribution (especially
so that when people make changes to infrastructure they can more easily
change all the users - there's been tons of synchronization problems with
"external packages"), but on the other hand some things would probably be
better maintained outside the core package.

Configure.help certainly isn't all that kernel version dependent, and
could successfully be maintained completely outside the kernel, I suspect.

And I know that I'm bad at maintaining documentation like this, simply
because I never use it, and I don't care enough. Trying to care about the
i18n version when I don't even understand what it says would be completely
impossible for me.

Comments?

		Linus

Re: Configure.help i18n system

[Horst von Brand]

Linus Torvalds <torvalds@transmeta.com> said:
> [ Kernel mailing list added to Cc ]
> On Thu, 7 Jun 2001, Keitaro Yosimura wrote:
> > Configure.help i18n system is the thing which uses MD5 SUM of the text
> > of the text as a key, and calls suitable data to the present language
> > setup (it judges from an environment variable).

[...]

> So I wonder if the Configure.help text should not possibly be even _more_
> distributed than just splitting it up into different files. It might very
> well be acceptable to actually distribute it over the net (and have just a
> mapping of config options into www-addresses or something).

I usually don't have a connection to the 'net when configuring a kernel...
and most people are like this, 24/7 Internet connections are still somewhat
of a rarity around here (and this country is "advanced" net-wise by non-US
standards). Plus adds the bloat of a browser to the configury.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Configure.help i18n system

[Richard Gooch]

Linus Torvalds writes:
> Configure.help certainly isn't all that kernel version dependent,
> and could successfully be maintained completely outside the kernel,
> I suspect.

It might not change much, but it can from time to time. The meaning of
a particular option can evolve over time. I wouldn't want to see
options have sections like "for kernel x.y.z the behaviour is this,
but for kernel a.b.c the behaviour is thus". It's just clutter.

Another issue is ease of use. I just want to be able to download a
single tarball, and then be able to go offline and configure, compile,
read docs and so on. One example of this is when setting up a new
box. Another is when I'm on the road, dial in and download a new patch
and then hop on a plane and start playing with it.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Configure.help i18n system

[GOTO Masanori]

At Thu, 7 Jun 2001 14:01:53 -0700 (PDT),
Linus Torvalds <torvalds@transmeta.com> wrote:
> On Thu, 7 Jun 2001, Keitaro Yosimura wrote:
> > 
> > Configure.help i18n system is the thing which uses MD5 SUM of the text
> > of the text as a key, and calls suitable data to the present language
> > setup (it judges from an environment variable).

I'm one of members to maintain one version of the Japanese Configure.help.
I also sent this question to Linus who coming in Japan, he denied this idea...

IMHO, using environment variable is not adequate; national language
designation should be set to the make option. The behavior of make
config must not be influenced by such a LANG environment variable.
You might concern about displaying national language character
(because it depends on the LANG variables), but it have merely
relations to `i18n text'.

> I suspect that this is actually something that intersects with the i18n
> work: how does the i18n projects distribute the actual help texts? Done
> right, maybe the same distributed environment could be used for
> everything, and getting Configure.help entirely out of the "core kernel"
> tree, and into a separate distribution (where the English version would be
> just one among many distributions).

Current distribution to the i18n texts are all outside from the core kernel...

BTW, i18n Configure.help needs `quality assuarance' because in English
all developers can recognize whether help text is correct or
not. However, i18n text can read for only each national people, so
developers cannot know about these correctness.  From this point of
view, I agree with Linus's comments because of this concerns.

But, there are some version of i18n Configure.help translations.
What a waste to make them sleep...

Regards,
-- GOTO Masanori