Re: CML2 design philosophy heads-up

[Jes Sorensen]

>>>>> "Eric" == Eric S Raymond <[e-mail]> writes:

Eric> Jes Sorensen <[e-mail]>:
>>  For a start, so far there has been no reason whatsoever to change
>> the format of definitions.

Eric> The judgment of the kbuild team is unanimous that you are
Eric> mistaken on this.  That's the five people (excluding me) who
Eric> wrote and maintained the CML1 code.  *They* said that code had
Eric> to go, Linus has concurred with their judgment, and the argument
Eric> is over.

Replacing the code does not require changing the style of the config
files. Thats a major problem with CML2, you introduce a new 'let me do
everything for you' tool that relies on a programming language that is
not being shipped by any major vendor nor does it look like they are
planning to do it anytime soon. And even if they start doing so, this
is a totally unreasonable requirement, you *must* to make it possible
to compile kernels on older distributions without requiring people to
update half of their system. On some architectures, the majority of
the users are still on glibc 2.0 and other old versions of
tools. Telling them to install an updated gcc for kernel compilation
is a necessary evil, which can easily be done without disturbing the
rest of the system. Updating the system's python installation is not a
reasonable request. Nobody disagrees that the Makefiles needs a
redesign, however that doesn't mean everything else has to be
redisigned in a totally incompatible manner.

Eric> If you persist in misunderstanding what I am doing, you are
Eric> neither going to be able to influence my behavior nor to
Eric> persuade other people that it is wrong.  Listen carefully,
Eric> please:

Oh I don't, on the other hand I see you consistently ignoring the
needs and requirements of the users. So far I haven't heard a single
developer say something positive about CML2, the most positive I have
heard so far has been "whatever", "it's his choice", "I don't care",
"I want to hack". The majority are of the "NO!" and "you got to be
kiddin'".

Eric> 1. The CML2 system neither changes the CONFIG_ symbol namespace
Eric> nor assumes any changes in it.  (Earlier versions did, but Greg
Eric> Banks showed me how to avoid needing to.)

Let's just say you didn't exactly give peoiple a good impression with
the trolling around on how everybody had to change their option names 
and how important it was for the world.

Eric> 2. The ruleset changes I have made simplify the configuration
Eric> process, but they do *not* in any way restrict the space of
Eric> configurations that are possible.  By design, every valid
Eric> (consistent) configuration in CML1 can be generated in CML2.  I
Eric> treat departures from that rule as rulesfile bugs and fix them
Eric> (as I just did at Ray Knight's instruction).

What spawned this recent discussion was you wanting to remove config
options and automatically enable things instead of giving the users
the explicit choice to do so. Now you are trying to tell me that you
are not changing things?

Eric> 3. I do not have (nor do I seek) the power to "impose" anything
Eric> on anyone.

We'll let that one stand on display for a few minutes.

Eric> You really ought to give CML2 a technical evaluation yourself
Eric> before you flame me again.  Much of what you seem to think you
Eric> know is not true.

So far I have had to deal with a number of requests from you trying to
impose unreasonable changes on developers. Thats more than plenty for
me. I do not have Python2 installed and I do not plan to, if you
change CML2 to use a reasonable programming language I might give it a
try.

Jes

PS: And if you could start making your .signature rfc1855 compliant it
was be pleasant for all readers of this mailing list.