Disgusted with kbuild developers

Disgusted with kbuild developers

[Jeff Garzik]

Ladies and gentlemen,

I would find this pathetic, if it didn't make me so mad.
Making an end run around the system, are we, Eric?

Small wonder the message below didn't make it to linux-kernel: 
suggestions would have been made that CML2 is DOA.

ESR's message to the kbuild list:
	http://marc.theaimsgroup.com/?l=kbuild-devel&m=101373619625183&w=2
The rest of the thread:
	http://marc.theaimsgroup.com/?t=101373623000001&r=1&w=2

For an open source "guru", Eric, you sure seem to like to turn to
cronyism and secret meetings when the going gets tough.

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> I would find this pathetic, if it didn't make me so mad.
> Making an end run around the system, are we, Eric?

No.  I'm doing what Dirk Hohndel recommended I do during a phone call
that happened at his initiative, last Friday morning.  

What "system" would you be referring to, anyway, Jeff?  Is there some
reason a respected open-source developer like Dirk who has concerns
should not have a conversation with Linus to address problems he thinks
are significant?  Is there some reason I should not have asked the kbuild
team members to give him appropriate background?

I don't understand what is upsetting you.  Is there some rule that all
conversations with Linus must go through Jeff Garzik?  If so, I was never
informed of it.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Dave Jones]

On Fri, Feb 15, 2002 at 11:51:47AM -0500, Eric S. Raymond wrote:

 > I don't understand what is upsetting you.  Is there some rule that all
 > conversations with Linus must go through Jeff Garzik?  If so, I was never
 > informed of it.

 No, but at the least keeping Linux-Kernel in the loop would be
 considered not just nice, but a somewhat more courteous method
 than 'sending someone around to go see Linus' when your pet
 project isn't getting the acceptance you hoped for.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Dave Jones <davej@suse.de>:
>  No, but at the least keeping Linux-Kernel in the loop would be
>  considered not just nice, but a somewhat more courteous method
>  than 'sending someone around to go see Linus' when your pet
>  project isn't getting the acceptance you hoped for.

No sending around is involved.  Dirk approached me, not the other
way around.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Larry McVoy]

On Fri, Feb 15, 2002 at 11:51:47AM -0500, Eric S. Raymond wrote:
> Jeff Garzik <jgarzik@mandrakesoft.com>:
> > I would find this pathetic, if it didn't make me so mad.
> > Making an end run around the system, are we, Eric?
> 
> What "system" would you be referring to, anyway, Jeff?  Is there some
> reason a respected open-source developer like Dirk who has concerns
> should not have a conversation with Linus to address problems he thinks
> are significant?  Is there some reason I should not have asked the kbuild
> team members to give him appropriate background?

Yeah, there is.  The point of *open* source is that it is *open*, Eric.
Jeff, if I understand him correctly, is making the point that if a
system can't stand up to public scrutiny, trying to get it in by private
campaigning is lame, not the open source way, and a little bit sleazy.

The open source development model depends on peer review, you might go
back and read some of your many essays on the topic.  Don't you take
commercial companies to task for doing exactly what you are doing?
Your actions are confusing, do your writings apply to other people but
not to you?  If there is some misunderstanding about your actions,
please clear it up.  If not, practice what you preach.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Larry McVoy <lm@bitmover.com>:
> Yeah, there is.  The point of *open* source is that it is *open*, Eric.
> Jeff, if I understand him correctly, is making the point that if a
> system can't stand up to public scrutiny, trying to get it in by private
> campaigning is lame, not the open source way, and a little bit sleazy.

So what "private campaigning" is going on here, exactly?  

Dirk approached me because he was concerned that politics and poor
communication might be getting in the way of some valuable work.  He
asked me to have the kbuild team fill him in on the background, and I
relayed that request.  The kbuild team's discussion with Dirk is
taking place on a public mailing list.

I'm bewildered.  What's the problem here?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Tom Rini]

On Fri, Feb 15, 2002 at 11:51:47AM -0500, Eric S. Raymond wrote:

> What "system" would you be referring to, anyway, Jeff?  Is there some
> reason a respected open-source developer like Dirk who has concerns
> should not have a conversation with Linus to address problems he thinks
> are significant?

Is there some reason this isn't being discussed on l-k again?  Lots of
people have concerns about the whole build system.  Ignoring the whole
python debate, there's actual issues about the CML2 package.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: Disgusted with kbuild developers

[Jeff Garzik]

"Eric S. Raymond" wrote:
> 
> Jeff Garzik <jgarzik@mandrakesoft.com>:
> > I would find this pathetic, if it didn't make me so mad.
> > Making an end run around the system, are we, Eric?
> 
> No.  I'm doing what Dirk Hohndel recommended I do during a phone call
> that happened at his initiative, last Friday morning.
> 
> What "system" would you be referring to, anyway, Jeff?  Is there some
> reason a respected open-source developer like Dirk who has concerns
> should not have a conversation with Linus to address problems he thinks
> are significant?  Is there some reason I should not have asked the kbuild
> team members to give him appropriate background?
> 
> I don't understand what is upsetting you.  Is there some rule that all
> conversations with Linus must go through Jeff Garzik?  If so, I was never
> informed of it.

Eric,

What I see on linux-kernel is you writing long diatribes, and then
promptly ignoring feedback from kernel developers who would actually be
using your system.  After months and months of being told that
Configure.help needed to be split up, you just continued to whine. 
Linus finally sat down and did it himself.  Back in December, Linus
talked about per-driver and/or per-subsystem metadata files, which would
contain (among other things) the config information.  That seems like a
sane option to me, and other developers agreed.  You ignored that too.

With regards to kbuild (not CML2), Keith publicly stated he didn't care
about 2.5.

I feel sorry about that you have troubled Dirk, without giving him all
the facts.

	Jeff


-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> What I see on linux-kernel is you writing long diatribes, and then
> promptly ignoring feedback from kernel developers who would actually be
> using your system.  After months and months of being told that
> Configure.help needed to be split up, you just continued to whine. 

I heard Linus say that he wanted Configure.help split up.  I agreed to
do it, too, in CML2.  But I thought I was not supposed to mess with existing 
formats -- in fact, I was afraid to, because you and Al Viro beat me up
so hard about changing *nothing* before cutover.  The CML1 code owns that
format, and I am not the CML1 maintainer.  In fact mec specifically turned
me down when I volunteered for that job; he said he wanted me concentrating
on CML2.

Neither Linus nor anyone else ever said to me "Eric, it's your job to 
make that change."  When I asked for guidance, Linus blackholed my mail.
Was I supposed to be practicing telepathy, here?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Alexander Viro]

On Fri, 15 Feb 2002, Eric S. Raymond wrote:

> I heard Linus say that he wanted Configure.help split up.  I agreed to
> do it, too, in CML2.  But I thought I was not supposed to mess with existing 
> formats -- in fact, I was afraid to, because you and Al Viro beat me up
> so hard about changing *nothing* before cutover.  The CML1 code owns that

Ah, now we see the violence inherent in the system.

> format, and I am not the CML1 maintainer.  In fact mec specifically turned
> me down when I volunteered for that job; he said he wanted me concentrating
> on CML2.
> 
> Neither Linus nor anyone else ever said to me "Eric, it's your job to 
> make that change."  When I asked for guidance, Linus blackholed my mail.

Oh!  Come and see the violence inherent in the system!
Help!  Help!  I'm being repressed!

> Was I supposed to be practicing telepathy, here?

Oh, what a dead giveaway.  Did you hear that, did you hear that, eh?
That's what I'm on about - did you see him repressing me, you saw it,
didn't you?


	Dennis^WEric, just one question: had it ever occured to you that
for a self-proclaimed "hacker of social systems" you are doing spectaculary
poor job?

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Alexander Viro <viro@math.psu.edu>:
> > Neither Linus nor anyone else ever said to me "Eric, it's your job to 
> > make that change."  When I asked for guidance, Linus blackholed my mail.
> 
> Oh!  Come and see the violence inherent in the system!
> Help!  Help!  I'm being repressed!

Your reply was pretty funny.  Well, I laughed anyway.

But laughter won't make the chronic communications problems go away.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Arjan van de Ven]

In article <20020215135557.B10961@thyrsus.com> you wrote:
> 
> But laughter won't make the chronic communications problems go away.

A "I don't like don't like <FOO> and won't apply it" is not a communications problem in general. When the person trying to submit <FOO> keeps submitting it without listening to suggestions or to reasons why it's not applied.... THEN there is a one sided communcation problem.

Not saying that's the case here, but it starts to appear to be so.

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Arjan van de Ven <arjan@fenrus.demon.nl>:
> A "I don't like don't like <FOO> and won't apply it" is not a communications problem in general. When the person trying to submit <FOO> keeps submitting it without listening to suggestions or to reasons why it's not applied.... THEN there is a one sided communcation problem.
> 
> Not saying that's the case here, but it starts to appear to be so.

Arjan, I would dearly love to get useful feedback on why things like my 
Configure.help patches weren't applied.  It would be a delight like 
water in the desert to *hear* some reasons!

But I think you know very well that the usual flow looks like this:

1. You throw a patch over the wall to Linus.

2. Either it shows up in the next release...

3. ...or you hear a vast and echoing silence.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Arjan van de Ven]

On Fri, Feb 15, 2002 at 02:14:33PM -0500, Eric S. Raymond wrote:
> Arjan, I would dearly love to get useful feedback on why things like my 
> Configure.help patches weren't applied.  It would be a delight like 
> water in the desert to *hear* some reasons!
> 
> But I think you know very well that the usual flow looks like this:
> 
> 1. You throw a patch over the wall to Linus.
> 
> 2. Either it shows up in the next release...
> 
> 3. ...or you hear a vast and echoing silence.

You're telling me Linus never mailed you about splitting up Configure.help ?

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Arjan van de Ven <arjan@pc1-camc5-0-cust78.cam.cable.ntl.com>:
> > But I think you know very well that the usual flow looks like this:
> > 
> > 1. You throw a patch over the wall to Linus.
> > 
> > 2. Either it shows up in the next release...
> > 
> > 3. ...or you hear a vast and echoing silence.
> 
> You're telling me Linus never mailed you about splitting up Configure.help ?

That's right.  The only time I ever saw Linus express an opinion on
this was in a post on lkml in which he said he didn't like the big
monolithic help file.  It didn't seem especially directed to me; I am
not the CML1 maintainer.

But I took it as a suggestion for CML2.  I told him I was willing to
do it after CML2 cutover, but was not sure he had considered the
ramifications for maintaining rulebase translations.  To this request
for clarification and guidance, I received no reply.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Dave Jones]

On Fri, Feb 15, 2002 at 02:54:21PM -0500, Eric S. Raymond wrote:

 > > You're telling me Linus never mailed you about splitting up Configure.help ?
 > That's right.  The only time I ever saw Linus express an opinion on
 > this was in a post on lkml in which he said he didn't like the big
 > monolithic help file.  It didn't seem especially directed to me; I am
 > not the CML1 maintainer.

 I recall the threads you mention.
 I also recall at least a half dozen regular contributors agreeing
 that splitting up Configure.help was the way forward.

 > But I took it as a suggestion for CML2.  I told him I was willing to
 > do it after CML2 cutover
 
 This is something I never understood. CML1 has served us for
 10 years or so, and suddenly its declared "unfixable".
 "I'm not hacking that, I'll fix it in CML2" seemed to become
 the attitude. End result ? Linus got pissed off with your
 complaints of non-inclusion, and _fixed_ one of the CML1 problems
 (Configure.help) And how long did it take ? ISTR it was around
 an hour after his first mail was sent to you, me & Jeff.
 1 hour. Versus the year you spent procrastinating about how
 CML2 would fix it.

 Sure CML2 fixes some bits that are not easily fixed in CML1,
 but I wonder sometimes how much of it is/was fixable.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Dave Jones <davej@suse.de>:
>  This is something I never understood. CML1 has served us for
>  10 years or so, and suddenly its declared "unfixable".

Yes, and not by me.  By the people who wrote it.

>  "I'm not hacking that, I'll fix it in CML2" seemed to become
>  the attitude. End result ? Linus got pissed off with your
>  complaints of non-inclusion, and _fixed_ one of the CML1 problems
>  (Configure.help) And how long did it take ? ISTR it was around
>  an hour after his first mail was sent to you, me & Jeff.
>  1 hour. Versus the year you spent procrastinating about how
>  CML2 would fix it.
> 
>  Sure CML2 fixes some bits that are not easily fixed in CML1,
>  but I wonder sometimes how much of it is/was fixable.

The first thing I heard, from mec two years ago, was "the CML1 code
base is not salvageable".  This was then and is now the unanimous opinion of
the kbuild team.  Not just mine; in fact, they concluded it before
I entered the picture.

I have seen nothing since to make me change that opinion.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Jeff Garzik]

"Eric S. Raymond" wrote:
> The first thing I heard, from mec two years ago, was "the CML1 code
> base is not salvageable".  This was then and is now the unanimous opinion of
> the kbuild team.  Not just mine; in fact, they concluded it before
> I entered the picture.
> 
> I have seen nothing since to make me change that opinion.

So Alan Cox's opinion counts as nothing?
mconfig counts as nothing?

Anyway, I think you are missing the point.  Sure, CML1 has problems, but
is your solution the one we want for the kernel?  I do not think that is
clear yet.  And bragging about a system's use in production tells us
little about its suitability for most kernel developers, or whether
you've addressed the global dependencies problem, or the syntax problem,
etc.

I'm sure CML2 configurator is whiz-bang, but it needs to do basic stuff
like having "make oldconfig" work exactly like it does in the current
config system.

	Jeff



-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Disgusted with kbuild developers

[Alan Cox]

>  Sure CML2 fixes some bits that are not easily fixed in CML1,
>  but I wonder sometimes how much of it is/was fixable.

Pretty much all of it. I wrote a proof of concept parser that can deduce
the set of rules that must be enforced and what must be changed when you
hit an option

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> >  Sure CML2 fixes some bits that are not easily fixed in CML1,
> >  but I wonder sometimes how much of it is/was fixable.
> 
> Pretty much all of it. I wrote a proof of concept parser that can deduce
> the set of rules that must be enforced and what must be changed when you
> hit an option

Alan.  It didn't work.  It couldn't have -- among other things, the old
language can't tell visibility from implication.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Alan Cox]

> > Pretty much all of it. I wrote a proof of concept parser that can deduce
> > the set of rules that must be enforced and what must be changed when you
> > hit an option
> 
> Alan.  It didn't work.  It couldn't have -- among other things, the old
> language can't tell visibility from implication.

The prototype generates a very convincing table set, and the tables generate
very convincing graphs. The information to work out what option needs another
as I've said for months

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> The prototype generates a very convincing table set, and the tables generate
> very convincing graphs. The information to work out what option needs another
> as I've said for months

I've *solved* this problem.  I understand the constraints.  I know 
exactly what you will have to do to get the rest of the way, *because
I did it*.

I have built not just a "proof of concept" but a working
implementation so robust that it is in production use by three
different projects.  And a substantial number of kernel developers are
using it now and reporting it good.

The good thing about working with developers like you and Dave Jones
and many of the other loonies on this list is that you are fucking
brilliant.  The bad thing is that because you're fucking brilliant,
you're often also ungodly arrogant about second-guessing other
peoples' work -- you think your snap judgment or "proof of concept" is
somehow equivalent to two years of design, coding and testing by
someone who has been concentrating on the problem.

News bulletin: IT'S NOT.

Alan, don't talk to me about "proof of concept".  Tell me about a
production-quality system, proven in use by people like Embedsys,
Webmachines, and the Compache project.  Tell me you can duplicate what
CML2 does successfully before you run around implying my design
assumptions are full of crap.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Alan Cox]

> > The prototype generates a very convincing table set, and the tables generate
> > very convincing graphs. The information to work out what option needs another
> > as I've said for months
> 
> I've *solved* this problem.  I understand the constraints.  I know 
> exactly what you will have to do to get the rest of the way, *because
> I did it*.

No you've replaced the system with one thats much harder to understand and
forces new tools on people. The *interesting* problem to solve is keeping
the existing infrastructure there and getting the same kind of results.

Since the information is there in CML1 to generate the list of constraints
for any given option, its a reasonable assertion that the entire CML2
language rewrite is self indulgence from a self confessed language invention
freak.

Alan

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Since the information is there in CML1 to generate the list of constraints
> for any given option,

False assumption...

>                    its a reasonable assertion that the entire CML2
> language rewrite is self indulgence from a self confessed language invention
> freak.

leading to a false result.

If you want to refute me, build it yourself.  You'll get a valuable learning
experience.  At the end of it, I'll have earned your apology.  Not that I
expect to get it.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Alan Cox]

> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > Since the information is there in CML1 to generate the list of constraints
> > for any given option,
> 
> False assumption...

Do you have anything more constructive that "doesnt" to say

> If you want to refute me, build it yourself.  You'll get a valuable learning
> experience.  At the end of it, I'll have earned your apology.  Not that I
> expect to get it.

Been there, done that, got the pretty graphs. Possibly the next step is to
redo the work into mconfig which already does pretty much anything we need
with the existing config files parsed using a real 100% genuine yacc grammar

Re: Disgusted with kbuild developers

[Martin Dalecki]

Alan Cox wrote:

>>Alan Cox <alan@lxorguk.ukuu.org.uk>:
>>
>>>Since the information is there in CML1 to generate the list of constraints
>>>for any given option,
>>>
>>False assumption...
>>
>
>Do you have anything more constructive that "doesnt" to say
>
>>If you want to refute me, build it yourself.  You'll get a valuable learning
>>experience.  At the end of it, I'll have earned your apology.  Not that I
>>expect to get it.
>>
>
>Been there, done that, got the pretty graphs. Possibly the next step is to
>redo the work into mconfig which already does pretty much anything we need
>with the existing config files parsed using a real 100% genuine yacc grammar
>
I second this. mconfig is a fine lean and sane design, which isn't 
trying to solve the "world hunger" problem.

Re: Disgusted with kbuild developers

[Jeff Garzik]

Alan Cox wrote:
> Since the information is there in CML1 to generate the list of constraints
> for any given option, its a reasonable assertion that the entire CML2
> language rewrite is self indulgence from a self confessed language invention
> freak.

Correct me if I'm wrong, but there are express two different types of
situations, and CML1 isn't sufficient to express the second:

1) CONFIG_FOO_OPTION requires CONFIG_FOO

2) CONFIG_SUBSYS2 requires CONFIG_SUBSYS1

The reason why #2 is different, is the desired prompting and symbol
behavior for the end user.

If CONFIG_SUBSYS1=m or "", and CONFIG_SUBSYS2=y or m, then we gotta
change the value of CONFIG_SUBSYS1 and options underneath
CONFIG_SUBSYS1.  Re-prompt for CONFIG_SUBSYS1, perhaps?
If CONFIG_SUBSYS1=y, value of CONFIG_SUBSYS2 isn't affected
If CONFIG_SUBSYS1="" and CONFIG_SUBSYS2="", then we gotta prompt for
CONFIG_SUBSYS1, but -after- CONFIG_SUBSYS2 is prompted for.

I was tempted to introduce a "requires" token to express dependencies
between subsystems, because I feel they are different from the other
dependencies present, 

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: Disgusted with kbuild developers

[Gerd Knorr]

Jeff Garzik wrote:
>  Alan Cox wrote:
> > Since the information is there in CML1 to generate the list of constraints
> > for any given option, its a reasonable assertion that the entire CML2
> > language rewrite is self indulgence from a self confessed language invention
> > freak.
>  
>  Correct me if I'm wrong, but there are express two different types of
>  situations, and CML1 isn't sufficient to express the second:
>  
>  1) CONFIG_FOO_OPTION requires CONFIG_FOO
>  
>  2) CONFIG_SUBSYS2 requires CONFIG_SUBSYS1
>  
>  The reason why #2 is different, is the desired prompting and symbol
>  behavior for the end user.
>  
>  If CONFIG_SUBSYS1=m or "", and CONFIG_SUBSYS2=y or m, then we gotta
>  change the value of CONFIG_SUBSYS1 and options underneath
>  CONFIG_SUBSYS1.  Re-prompt for CONFIG_SUBSYS1, perhaps?

IMHO that is a issue with the current *tools*, not with the CML1
*language*.  The information about the dependences is there, a more
clever tool than "make config" can use them to present a better UI.

I have a 5-year-old perl script for kernel configuration, maybe
I should try to reactivate it and see ...

  Gerd

-- 
#define	ENOCLUE 125 /* userland programmer induced race condition */

Re: Disgusted with kbuild developers

[Alan Cox]

> 1) CONFIG_FOO_OPTION requires CONFIG_FOO
> 2) CONFIG_SUBSYS2 requires CONFIG_SUBSYS1
> 
> The reason why #2 is different, is the desired prompting and symbol
> behavior for the end user.

You can tell a subsystem from a module quite reliably because it has a 
subtree of dependant questions. Now you might get it wrong, but its still
correct to prompt for the subtree of questions again since if you've just
forced on eepro100 for example, you do want to be asked mmio/pio and the
like

> If CONFIG_SUBSYS1="" and CONFIG_SUBSYS2="", then we gotta prompt for
> CONFIG_SUBSYS1, but -after- CONFIG_SUBSYS2 is prompted for.

The graph tells you that. The only interesting case I could find is the
negation one - some rules are  A conflicts with B which makes the UI side
much more fun

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> The graph tells you that. The only interesting case I could find is the
> negation one - some rules are  A conflicts with B which makes the UI side
> much more fun

That's right.  This is a CML2 require/prohibit construct.  CML1 cannot
express this, and it's essential for side-effect forcing to work.  Jeff's
observation about being tempted to introduce a `require' turns out actually 
to be equivalent once you see how both problems generalize.

You can't deduce these constraints from graph analysis, because they're 
not implicit in the if/then tree structure that is the only thing CML1
knows about.

Jeff and Alan have now almost caught up to where I was two years ago when
I realized the CMl1 formalism was inadequate.

This is going in the FAQ.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Rob Landley]

On Friday 15 February 2002 04:46 pm, Eric S. Raymond wrote:

> Alan, don't talk to me about "proof of concept".  Tell me about a
> production-quality system, proven in use by people like Embedsys,
> Webmachines, and the Compache project.  Tell me you can duplicate what
> CML2 does successfully before you run around implying my design
> assumptions are full of crap.

Eric, step back a sec.  Deep breaths.

Nobody ever said CML1 had to be able to serve projects other than 
linux-kernel.  The fact CML2 can is nice, but irrelevant.  That argument goes 
nowhere.

The amount of time you've invested in your code isn't particularly 
interesting to anybody but you, except as an unreliable yardstick of how long 
it might take to duplicate things.  The "genius from mars" technique might be 
able to come up with an even better way in a week, you never know.  (Even a 
really hard problem space can be elegantly solved out of left field.  It's 
not likely, but you never know.)

The other side of the argument is that a proof of concept is not the same 
thing as actually solving the problem.  You have working code.  Several other 
people have unimplemented theoretical proposals, tests, and prototypes that 
don't actually do anything useful as of yet.  That's the main argument you 
should probably be making.

If people want to prove Eric wrong, then make CML1 work well.  If you believe 
it's not as hard a problem as he says it is, then by all means prove him 
wrong.  Arguing about how hard the problem really would be to solve, without 
actually solving it...  Why?

Rob

Re: Disgusted with kbuild developers

[Pavel Machek]

Hi!

> Alan, don't talk to me about "proof of concept".  Tell me about a
> production-quality system, proven in use by people like Embedsys,
> Webmachines, and the Compache project.  Tell me you can duplicate what

What are you trying to say? New configuration system needs to be
tested by big company before you want to hear about it?

"I do not care what kernel developers say, they are all stupid, but my
stuff is used by Embedsys, Webmachines and Compache, so it must be
good and you are all stupid."

No wonder Linus ignores you.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Pavel Machek <pavel@suse.cz>:
> What are you trying to say? New configuration system needs to be
> tested by big company before you want to hear about it?

No, of course not.  Two of the three projects I cited are open-source
developments.

My point should have been obvious.  Alan is talking as though his
supposed "proof of concept" is as good an argument as a tested,
production-quality system.  Of course, it is not.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Robert Love]

On Fri, 2002-02-15 at 15:38, Dave Jones wrote:

>  This is something I never understood. CML1 has served us for
>  10 years or so, and suddenly its declared "unfixable".
>  "I'm not hacking that, I'll fix it in CML2" seemed to become
>  the attitude. End result ? Linus got pissed off with your
>  complaints of non-inclusion, and _fixed_ one of the CML1 problems
>  (Configure.help) And how long did it take ? ISTR it was around
>  an hour after his first mail was sent to you, me & Jeff.
>  1 hour. Versus the year you spent procrastinating about how
>  CML2 would fix it.

Amen.  This whole "CML1 vs CML2" thing is silly.  We don't see other
"maintainers" refusing to touch code, having no relation to code, and
then coming out of no-where and offering some external solution for the
perceived problem.

If you _develop_ kernel code and see a problem with the configure
system, then fix the problems.  As Linus says, let stuff evolve.

>  Sure CML2 fixes some bits that are not easily fixed in CML1,
>  but I wonder sometimes how much of it is/was fixable.

Agreed, but CML2 has a whole bunch of new "features" too which will be
shoved down our throats!!

	Robert Love

Re: Disgusted with kbuild developers

[Dave Jones]

On Fri, Feb 15, 2002 at 05:08:42PM -0500, Robert Love wrote:
 > >  Sure CML2 fixes some bits that are not easily fixed in CML1,
 > >  but I wonder sometimes how much of it is/was fixable.
 > Agreed, but CML2 has a whole bunch of new "features" too which will be
 > shoved down our throats!!

 Increased functionality I don't have a problem with, as long
 as other more important things are addressed.  And for that matter,
 Linus has said to Eric "I don't care, take this out of the
 kernel completely leaving just oldconfig'. 

 It might just be the sanest choice, and leave all this discussion
 in userland.
 
-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Dave Jones <davej@suse.de>:
>  Increased functionality I don't have a problem with, as long
>  as other more important things are addressed.  And for that matter,
>  Linus has said to Eric "I don't care, take this out of the
>  kernel completely leaving just oldconfig'. 
> 
>  It might just be the sanest choice, and leave all this discussion
>  in userland.

CML2 can live in userland.  It already does; three other projects use it.
The kernel rulebase cannot.  The real issue here is whether the CML1 
language carries sufficient information to support things like 
side-effect deduction.  And the answer is "no".
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Alan Cox]

> The kernel rulebase cannot.  The real issue here is whether the CML1 
> language carries sufficient information to support things like 
> side-effect deduction.  And the answer is "no".

Thats an opinion not an answer. What doesn't it contain ?

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > The kernel rulebase cannot.  The real issue here is whether the CML1 
> > language carries sufficient information to support things like 
> > side-effect deduction.  And the answer is "no".
> 
> Thats an opinion not an answer. What doesn't it contain ?

New FAQ entry:

* Inventing CML2 was unnecessary, since CML1 carries enough information to
  do consistency checking and side-effect forcing.

Jeff Garzik observed:
>I was tempted to introduce a "requires" token to express dependencies
>between subsystems, because I feel they are different from the other
>dependencies present,

Alan followed up with:
>The only interesting case I could find is the negation one - some
>rules are A conflicts with B which makes the UI side much more fun

Jeff and Alan have put their finger neatly on one of the key bits CML2
can do that CML1 cannot -- express cross-directory dependencies in
such a way that the configurator can force side effects in both
directions.  This is, in fact, the very rock on which my original
attempt to save CML1 foundered after six weeks of effort.

-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Alan Cox]

> Jeff and Alan have put their finger neatly on one of the key bits CML2
> can do that CML1 cannot -- express cross-directory dependencies in
> such a way that the configurator can force side effects in both
> directions.  This is, in fact, the very rock on which my original
> attempt to save CML1 foundered after six weeks of effort.

You can force a side effect in both directions. The language provides the
information to do that, the current -toolset- can't handle this.

At any point you ask a question you can "wind back" and compute the set
of changes that are needed and re-ask only the needed questions.

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> You can force a side effect in both directions. The language provides the
> information to do that, the current -toolset- can't handle this.
> 
> At any point you ask a question you can "wind back" and compute the set
> of changes that are needed and re-ask only the needed questions.

I spent over a month in early 2000 trying a similar approach.  I tried it
with CML1, and I tried it with increasingly enriched dialects of CML1
(magic comments carrying extra semantic information, that sort of thing).

The results were (a) ugly, and (b) broken.  I struggled against this
for a long time, because I knew what a horrible revolving bitch and
maintaining a parallel rulebase in a new formalism was going to be.

As you no doubt realize, the problem of deducing the forcing
information from CMl1 markup is efectively equivalent to the problem
of writing a mechanical CML1-to-CML2 translator.  So I have a
suggestion: if you want to prove that it's possible to extract all the
info for side-effect forcing from CML1, do it by writing such a
translator.

I believe you will fail, as I did and as Jeff Garzik implicitly predicted.
If you fail, the process will teach you what I had to learn the hard way 
two years back.  If you succeed, people who are whingeing about wanting
a bug-for-bug rulebase translation will get what they want.

Don't tell me to do it.  Been there, done that, have the battle scars.
If there were any way I could have avoided maintaining my own rulebase,
you better believe I'd have done it.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Jeff Garzik]

"Eric S. Raymond" wrote:
> I believe you will fail, as I did and as Jeff Garzik implicitly predicted.

no, I didn't, don't put imaginary words in my mouth.

-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Disgusted with kbuild developers

[Alan Cox]

> of writing a mechanical CML1-to-CML2 translator.  So I have a
> suggestion: if you want to prove that it's possible to extract all the
> info for side-effect forcing from CML1, do it by writing such a
> translator.

I'd rather focus on making the existing tools better. If you want to 
convert the data into Erics pet format on the fly *you* do the work.

Re: Disgusted with kbuild developers

[Jeff Garzik]

Alan Cox wrote:
> 
> > Jeff and Alan have put their finger neatly on one of the key bits CML2
> > can do that CML1 cannot -- express cross-directory dependencies in
> > such a way that the configurator can force side effects in both
> > directions.  This is, in fact, the very rock on which my original
> > attempt to save CML1 foundered after six weeks of effort.
> 
> You can force a side effect in both directions.

Yup, good point.

I mentioned "requires" as a way of avoiding 'both directions' in some
cases.

	Jeff


-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Disgusted with kbuild developers

[Jeff Garzik]

Dave Jones wrote:
>  Increased functionality I don't have a problem with, as long
>  as other more important things are addressed.  And for that matter,
>  Linus has said to Eric "I don't care, take this out of the
>  kernel completely leaving just oldconfig'.

That's a good point, and one I would be happy with.  (or, ditch -all-
current config code, and replace with the existing mconfig)

Eric's configurator definitely seems to have a place with users.  Making
kernel configuration easier for the masses is more than fine with me... 
Impacting kernel developers' productivity and workflow because of this
is more of what I object to...

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: Disgusted with kbuild developers

[Matthias Andree]

On Sat, 16 Feb 2002, Jeff Garzik wrote:

> Dave Jones wrote:
> >  Increased functionality I don't have a problem with, as long
> >  as other more important things are addressed.  And for that matter,
> >  Linus has said to Eric "I don't care, take this out of the
> >  kernel completely leaving just oldconfig'.
> 
> That's a good point, and one I would be happy with.  (or, ditch -all-
> current config code, and replace with the existing mconfig)

If so, then fairness of mconfig vs. CML2 tools should command that
mconfig's "old" mode works properly first. I reported to Christoph that
it always reprompts me about the kernel core format (a.out vs. ELF),
which is something "make oldconfig" does not do with the same config, he
acknowledged the bug, but I have yet to see the fix.

> Eric's configurator definitely seems to have a place with users.  Making
> kernel configuration easier for the masses is more than fine with me... 
> Impacting kernel developers' productivity and workflow because of this
> is more of what I object to...

Does that really happen? It looks as though the conversion of the
current config.in stuff has been completed as part of the CML2 suite.

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> Impacting kernel developers' productivity and workflow because of this
> is more of what I object to...

I still don't get why you think CML2 is going to interfere with your
workflow.  Would you explain this to me, please?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Jeff Garzik]

"Eric S. Raymond" wrote:
> 
> Jeff Garzik <jgarzik@mandrakesoft.com>:
> > Impacting kernel developers' productivity and workflow because of this
> > is more of what I object to...
> 
> I still don't get why you think CML2 is going to interfere with your
> workflow.  Would you explain this to me, please?

(please read "CML2 feedback" message before this...)

Ideally in the future I can add and update a driver's makefile and
configuration information by patching drivers/net/netdriver.c and
drivers/net/netdriver.conf, and touch absolutely no other files.

	Jeff



-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Possible breakthrough in the CML2 logjam?

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> Ideally in the future I can add and update a driver's makefile and
> configuration information by patching drivers/net/netdriver.c and
> drivers/net/netdriver.conf, and touch absolutely no other files.

That's very much the direction I'd like to go in, Jeff.  I'm
surprised and delighted to hear you say this.  You're actually
anticipating my plans for six months down the road.  Maybe we
have some common ground here.

One of the objectives of the CML2 language design is to make it
amenable to being generated by a metadata analyzer.  I mean some very
specific things by this.

One important property which CML2 declarations have that CML1 syntax
does not is that (a) they're not order-dependent, and (b) they have
strong locality (that is, the syntactic context of a single
declaration holds all the semantic information -- you don't have to go
monkey-climbing up a bunch of enclosing syntax to parse it, or
*generate* a bunch of enclosing syntax to express it).

These properties tremendously simplify generating a rulebase from
(so far hypothetical) analysis tools.  My first step would be to 
automatically generate CML2 bus-guard information from annotations
in the driver sources.  Once I write a tool that can do that, I can whack
about 25% of the rulebase, including most of the parts that are a 
maintainance headache.

My longer-term plan is to whittle away at the manually-maintained
rulebase until nothing but menu structure and a handful of cross-
directory requirements are left.  Everything else should be generated
by a program that turns source-code metadata into stereotyped CML2
markup.  

Even a lot of the menu structure might be generatable, requiring it
to be specified only in exception cases where as a matter of UI design
choice you don't want to track the code hierarchy.

This has been part of my long-term plan since about eighteen months
ago.  It's had a major, *major* impact on the language design.  In
particular it's one of the reasons visibility and implication 
can be declared separately from the menu structure.

If you go back and look at the language design from this point of view,
I think many things you might not have seen the point of before will
become clearer.

Note well two points:

1.  This can't practicably be done in CML1.  CML1 markup has crappy
locality; the metadata analyzer would have to carry around way too
much state about other symbols in order to generate the markup for any
given one.

2. This design basically demands a single-apex tree.  Otherwise I don't
think you can get the consistency-checking right -- I haven't been 
able to invent a method to do it, anyway.

So if you want this, please start backing CML2 and contributing in a
positive way.  I know how to get where you want to go.  CML2 is
specifically intentionally designed to make it possible, and I have the
will to follow through.

But for these good things to happen, CML2 *got to go in*.  I cannot both
continue the enormous effort of maintaining a parallel rulebase
and move the ball forward towards automatic rule generation from metadata
and other good things.  That's what I want to be working on.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Possible breakthrough in the CML2 logjam?

[Jeff Garzik]

"Eric S. Raymond" wrote:
> But for these good things to happen, CML2 *got to go in*.  I cannot both
> continue the enormous effort of maintaining a parallel rulebase
> and move the ball forward towards automatic rule generation from metadata
> and other good things.  That's what I want to be working on.

Global dependencies...  CML1 doesn't have this now, and it needs never
to have it.  This is no point in merging a design change of that
magnitude only to take it away later on.  Further, merging a rulebase
which contains such dependencies would be a huge mistake that might take
years to undo.  drivers/net/rules.cml doesn't need S/390 stuff in it,
AFAICT, and that is a simple example of a bug found in many of the
rules.cml files.

	Jeff



-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Possible breakthrough in the CML2 logjam?

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> Global dependencies...  CML1 doesn't have this now, and it needs never
> to have it.  This is no point in merging a design change of that
> magnitude only to take it away later on.  Further, merging a rulebase
> which contains such dependencies would be a huge mistake that might take
> years to undo.  drivers/net/rules.cml doesn't need S/390 stuff in it,
> AFAICT, and that is a simple example of a bug found in many of the
> rules.cml files.

All right.  There are a couple of ways we can attack this -- I have
some ideas.  But I want a meta-question answered first.  If we solve
this issue, *are you on board*?

I've got to get off the fscking treadmill I'm on now where I'm spending
so much time on the parallel-rulebase maintainance and the flaming
politics that I can't really get anything else done.  

After what you wrote upthread, I don't think you want me to be stuck
either.  Fact: ain't nobody else visible with both the motivation and
skills to tackle what you want done.  I've been thinking about
metadata-centered configuration and consciously bending CML2's design
towards it for longer than anyone else has even been considering the
problem.

I *will* get us there -- I think the last two years have demonstrated
my determination.  But to do it, I need alliance rather than
obstruction. I need you to tell Linus that your concerns have been met
and sponsor CML2 to go in, so I can stop perpetually re-fighting old
battles.

Because we agree on getting to metadata-centered configuration, your
requirements list now appears to have shrunk to one.  You want to
"eliminate global depencies".  I hear that.  I got it.  

What I want to know is that this is not a proxy for "CML2 can never be
good enough" and that you'll be pulling more objections out of your butt
till the Sun goes nova.  Because if that's true there's no point in
my trying to work with you. 

But if "eliminate global depencies" is it, we can be allies, because 
ultimately we both want to get the config system to the same place. 
I've taken the first, biggest step -- from imperative code to 
declaration/constraint language.  The second -- from a
declaration/constraint language to a metadata-centered system -- 
will be easier.

A positive answer may be "Yes, that's it, let's go forward", or
"Almost, there are a couple other minor and negotiable issues *which I
will now list*" (where "Minor and negotiable" = "I don't have to scrap
my architecture").
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Possible breakthrough in the CML2 logjam?

[Jeff Garzik]

"Eric S. Raymond" wrote:
> But if "eliminate global depencies" is it, we can be allies, because
> ultimately we both want to get the config system to the same place.
> I've taken the first, biggest step -- from imperative code to
> declaration/constraint language.  The second -- from a
> declaration/constraint language to a metadata-centered system --
> will be easier.

Well, let's simmer things down a bit and see what other people have to
say.  Maybe I'm completely off base.

But to answer the question which the subtext seemed to asking (at least
to me), no, there is no vendetta against you.  And for the record on a
specific detail, I have no problem with python use.  If I have no major
objection based purely on technical grounds, that what you'll be hearing
from me.

And further, in 2.5.x series at least, minor objections can be worked
through after a kernel merge.  But major objections... that's not the
time when something -must- -go- -in-.

Regards,

	Jeff



-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Possible breakthrough in the CML2 logjam?

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> Well, let's simmer things down a bit and see what other people have to
> say.  Maybe I'm completely off base.

Jeff, I'm not asking "other people".  I'm asking *you*.  

You're one of the people Linus says he trusts.  Linus has said,
explicitly, to myself and Dave Jones, on this very issue, "get me out
of the loop".  My take is that if you switch from opposing CML2 to
supporting it, the political wars will probably be about over.

I hope the prospect of actually getting to a metadata-centered
configuration system in our lifetime will be sufficient incentive for
you to do so.  Oh lovely dream...I could have a prototype
metadata-to-CML2-bus-guards translator in less than two weeks, I
think, if I didn't have to maintain the CML2 rulebase all by myself.  I
want to go there.

> But to answer the question which the subtext seemed to asking (at least
> to me), no, there is no vendetta against you.  And for the record on a
> specific detail, I have no problem with python use.  If I have no major
> objection based purely on technical grounds, that what you'll be hearing
> from me.

OK.  Is "global dependencies" your sole technical showstopper?  If so,
can we dispose of the ill-defined "CML2 will fuck up my workflow" thing?

If you tell me yes, we can move to a discussion of why global
dependencies are a problem and how to solve it.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Possible breakthrough in the CML2 logjam?

[Jeff Garzik]

"Eric S. Raymond" wrote:
> 
> Jeff Garzik <jgarzik@mandrakesoft.com>:
> > Well, let's simmer things down a bit and see what other people have to
> > say.  Maybe I'm completely off base.
> 
> Jeff, I'm not asking "other people".  I'm asking *you*.
> 
> You're one of the people Linus says he trusts.  Linus has said,
> explicitly, to myself and Dave Jones, on this very issue, "get me out
> of the loop".  My take is that if you switch from opposing CML2 to
> supporting it, the political wars will probably be about over.

Shit... don't inflate my stock more than it's worth.

I'm not giving a pre-blessing to any, but I'm willing to give something
an honest and fair review.

	Jeff



-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Possible breakthrough in the CML2 logjam?

[Felix von Leitner]

Thus spake Eric S. Raymond (esr@thyrsus.com):
> Jeff, I'm not asking "other people".  I'm asking *you*.  

> You're one of the people Linus says he trusts.

Eric, why don't you try to make a system that is not openly disgusting
and revolting?  The kernel affects everyone.  Bribing congress is a
tactic worthy of Microsoft, not of you.  Please concentrate on making
good software and not on fast talking to Jeff until he takes a
sabbatical to get some rest at all.

The more of your mails about CML I see, the more I am disgusted with it.

'revolting' overemphasizes personal beliefs && religion

[bert hubert]

On Mon, Feb 18, 2002 at 06:27:43PM +0000, Felix von Leitner wrote:
> Thus spake Eric S. Raymond (esr@thyrsus.com):
> > Jeff, I'm not asking "other people".  I'm asking *you*.  
> 
> > You're one of the people Linus says he trusts.
> 
> Eric, why don't you try to make a system that is not openly disgusting
> and revolting?  The kernel affects everyone.  Bribing congress is a
> tactic worthy of Microsoft, not of you.  Please concentrate on making

Felix, while I respect you for your work on dietlibc, calling anything that
is not written in hardcore C 'revolting' is missing the point.

> The more of your mails about CML I see, the more I am disgusted with it.

And the world yawns. We do not care for (your) religious beliefs, we care
*for facts*. Religion has no place in technology. 

If you have an opinion, voice it without referring to how a program makes
*you* feel. Voice it by stating how it should make everybody feel, based on
technical arguments.

So I could say that I find your attitude disgusting, and I do, but that's
not helping anybody. So instead I'll state that your arguments are
counterproductive because they are only valid in the belief system of Felix
von Leitner, and make no sense to others with differing belief systems.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc

Re: Possible breakthrough in the CML2 logjam?

[Larry McVoy]

> I need you to tell Linus that your concerns have been met
> and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> battles.

That's a fine thing for anyone and everyone to say *after* they have
used the system and like it.

If you are asking for a blessing in advance, which is how I read that,
I would think there is zero chance of that happening, it's not how work
is done on the kernel.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Possible breakthrough in the CML2 logjam?

[Eric S. Raymond]

Larry McVoy <lm@bitmover.com>:
> > I need you to tell Linus that your concerns have been met
> > and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> > battles.
> 
> That's a fine thing for anyone and everyone to say *after* they have
> used the system and like it.
> 
> If you are asking for a blessing in advance, which is how I read that,
> I would think there is zero chance of that happening, it's not how work
> is done on the kernel.

We're talking about design objections here.  Specific objections to actual
CML2 bugs, including rulebase and UI bugs, are a different level.  What
I am asking is if Jeff will bless the *architecture* provided the global-
dependency issue is met.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Possible breakthrough in the CML2 logjam?

[Jeff Garzik]

"Eric S. Raymond" wrote:
> Larry McVoy <lm@bitmover.com>:
> > > I need you to tell Linus that your concerns have been met
> > > and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> > > battles.
> >
> > That's a fine thing for anyone and everyone to say *after* they have
> > used the system and like it.
> >
> > If you are asking for a blessing in advance, which is how I read that,
> > I would think there is zero chance of that happening, it's not how work
> > is done on the kernel.
> 
> We're talking about design objections here.  Specific objections to actual
> CML2 bugs, including rulebase and UI bugs, are a different level.  What
> I am asking is if Jeff will bless the *architecture* provided the global-
> dependency issue is met.

Larry's right.  I won't (and notice, did not in previous e-mail) provide
a pre-blessing.  I will promise to be fair.

But as I said, let's wait a bit and see what others say.  Alan for
example noted that bit about improving the existing tools.

	Jeff



-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Possible breakthrough in the CML2 logjam?

[Larry McVoy]

On Sat, Feb 16, 2002 at 12:16:34PM -0500, Eric S. Raymond wrote:
> Larry McVoy <lm@bitmover.com>:
> > > I need you to tell Linus that your concerns have been met
> > > and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> > > battles.
> > 
> > That's a fine thing for anyone and everyone to say *after* they have
> > used the system and like it.
> > 
> > If you are asking for a blessing in advance, which is how I read that,
> > I would think there is zero chance of that happening, it's not how work
> > is done on the kernel.
> 
> We're talking about design objections here.  Specific objections to actual
> CML2 bugs, including rulebase and UI bugs, are a different level.  What
> I am asking is if Jeff will bless the *architecture* provided the global-
> dependency issue is met.

See your quote above which contains "and sponsor CML2 to go in".  Code is 
what goes in.  Having the right architecture is great, we all agree, but
what goes in is code.  So your question above is basically "if I do this
will you pressure Linus to accept my *code*".  The answer to that should
always be "no".  You're trying to do an end run around the process.  The
process here is to let people see the changes, try the changes, refine 
the changes, and when they are ready, Linus accepts the changes.  Nowhere
in that process is any deal making.  What you are doing is a lot like the
skating judges, making deals.  Your code should go in evaluated on its
merits.  That's the beauty of the system.  It doesn't matter who *you*
are, the code is the only thing.  So you can be universally loved and
your code might not make it in.  You can be universally hated, and your
code can make it in.  That's a pretty cool system and I'd suggest that
you stop trying to work around it and just make your code be something 
that people want.  Then it will go in.  No deals necessary.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Possible breakthrough in the CML2 logjam?

[Rogier Wolff]

Larry McVoy wrote:
> On Sat, Feb 16, 2002 at 12:16:34PM -0500, Eric S. Raymond wrote:
> > Larry McVoy <lm@bitmover.com>:
> > > > I need you to tell Linus that your concerns have been met
> > > > and sponsor CML2 to go in, so I can stop perpetually re-fighting old
> > > > battles.
> > > 
> > > That's a fine thing for anyone and everyone to say *after* they have
> > > used the system and like it.
> > > 
> > > If you are asking for a blessing in advance, which is how I read that,
> > > I would think there is zero chance of that happening, it's not how work
> > > is done on the kernel.
> > 
> > We're talking about design objections here.  Specific objections to actual
> > CML2 bugs, including rulebase and UI bugs, are a different level.  What
> > I am asking is if Jeff will bless the *architecture* provided the global-
> > dependency issue is met.
> 
> See your quote above which contains "and sponsor CML2 to go in".  Code is 
> what goes in.  Having the right architecture is great, we all agree, but
> what goes in is code.  So your question above is basically "if I do this
> will you pressure Linus to accept my *code*".  The answer to that should
> always be "no". 

Sometimes I'm willing to vouch for the quality of the *code*, and I
want a "go ahead and do it" from the kernel crowd.

Writing the code without consensus on the architecture can make you
have to go back to architecting when people have architectural
objections. 

Part of the problem is that in a company the manager is in the end
responsible for the salary of the guy doing the work. So he'll work
along an try to make a good architecture before doing the actual
coding.

For Linus it costs just one Email to say: "Hmm. Maybe. Show me the
code!", and reject the code later on. 


	Roger.

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: Disgusted with kbuild developers

[Larry McVoy]

On Fri, Feb 15, 2002 at 02:54:21PM -0500, Eric S. Raymond wrote:
> Arjan van de Ven <arjan@pc1-camc5-0-cust78.cam.cable.ntl.com>:
> > > But I think you know very well that the usual flow looks like this:
> > > 
> > > 1. You throw a patch over the wall to Linus.
> > > 
> > > 2. Either it shows up in the next release...
> > > 
> > > 3. ...or you hear a vast and echoing silence.
> > 
> > You're telling me Linus never mailed you about splitting up Configure.help ?
> 
> That's right.  

Gimme a break.  I read those posts, I repeatedly saw that people said to do 
that, I don't remember if it was Linus or not, but it's not like he has the
only brain.  The clearly expressed sentiment was to put the help next to the
source.  You repeatedly came up with corner cases where that wouldn't work
and used that as an excuse to do nothing.  Having just gone through the same
thing with Linus about BK locking, I can assure you that dredging up the
corner cases does not work, you might as well get to work and solve the 
problem.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Larry McVoy <lm@bitmover.com>:
> Gimme a break.  I read those posts, I repeatedly saw that people said to do 
> that, I don't remember if it was Linus or not, but it's not like he has the
> only brain.  The clearly expressed sentiment was to put the help next to the
> source.  You repeatedly came up with corner cases where that wouldn't work
> and used that as an excuse to do nothing.

And one of those corner cases in fact came around and bit us on the ass.

If we had handled the transition the smooth way I wanted to, and was
prepared to, we'd still have a maintainable help database spanning 2.4
as well as 2.5.  As it is, Linus blew my system into flinders and 
obsoleted all my tools (I'm not talking CML2 itself now but the machinery I
wrote for tracking help changes).

As a result, I had to tell Marcelo I had no choice but to drop maintaining
the 2.4 help file.  The divergence, and the damage, is probably not
recoverable.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Dave Jones]

On Fri, Feb 15, 2002 at 03:39:53PM -0500, Eric S. Raymond wrote:

 > As a result, I had to tell Marcelo I had no choice but to drop maintaining
 > the 2.4 help file.  The divergence, and the damage, is probably not
 > recoverable.

 find . -name Config.help -exec cat {} >Configure.help \;

 Ok, they'll perhaps not be in the same order as your original
 working set, but that issue goes away when you split your
 set up with the tools Linus gave you, and regenerate.
 
 Maintaining is hard, lets go shopping.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Dave Jones <davej@suse.de>:
>  > As a result, I had to tell Marcelo I had no choice but to drop maintaining
>  > the 2.4 help file.  The divergence, and the damage, is probably not
>  > recoverable.
> 
>  find . -name Config.help -exec cat {} >Configure.help \;

Back-seat drivers.  Answers for everything, understanding of nothing.

Sorry, it's not *nearly* that simple.  For one thing, one of the fourteen
billion requirements I've had dropped on me is that Marcelo doesn't want
any symbols in his help file that aren't actually in the 2.4 rulebase.

So I'd have to generate a custom version for him.  I used to have the
machinery to do that by parsing magic comments in my master file.  
Until Linus blew it apart.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Dave Jones]

On Fri, Feb 15, 2002 at 03:58:17PM -0500, Eric S. Raymond wrote:
 > Back-seat drivers.  Answers for everything, understanding of nothing.

 *plonk*

 > Sorry, it's not *nearly* that simple.  For one thing, one of the fourteen
 > billion requirements I've had dropped on me is that Marcelo doesn't want
 > any symbols in his help file that aren't actually in the 2.4 rulebase.

 As you obviously completely ignored my previous point, I'll reiterate it.

 1. You run Linus' split-into-config.in script on a 2.4 tree.
 2. You add whatever Config.ins have been updated to the 2.4 config.ins
 3. You regenerate with the find example I showed in the other mail.

 There. 2.4 Configure.help up to date with latest symbols, but
 containing none of the 2.5 ones.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Dave Jones <davej@suse.de>:
>  As you obviously completely ignored my previous point, I'll reiterate it.
> 
>  1. You run Linus' split-into-config.in script on a 2.4 tree.
>  2. You add whatever Config.ins have been updated to the 2.4 config.ins
>  3. You regenerate with the find example I showed in the other mail.
> 
>  There. 2.4 Configure.help up to date with latest symbols, but
>  containing none of the 2.5 ones.

And you've completely ignored the real problem...which is when I get
a text change for one tree, *how do I automatically propagate it to
the other*?  How do I *tell* that it ought to be propagated?  

It's not sufficient to develop a one-shot conversion procedure.  What
I came up with had to allow me to continue generating correct help 
files for all trees under the assumption that text changes for 2.4
could come in against the 2.5 copy of the help entry, or vice-versa --
bearing in mind that some symbols have divergent text and that's correct.

Solutions that involve me doing an arbitrary and increasing amount of
hand-hacking on every release are right out.

If you think this problem through, I'm sure you'll come up with a
design very similar to what I actually built.  Which, by Linus's
choice, got irrecoverably nuked.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Dave Jones]

On Fri, Feb 15, 2002 at 05:04:59PM -0500, Eric S. Raymond wrote:

 > And you've completely ignored the real problem...which is when I get
 > a text change for one tree, *how do I automatically propagate it to
 > the other*?  How do I *tell* that it ought to be propagated?  

 Depends on the context of the change.
 In a majority of cases the answer is RTFC.
 If this is too much effort, rethink your outlook on whats
 involved as 'maintainer' of something like the Config.help's.
 
 This is precisely the reason that splitting them was the best
 thing that could have happened. They are now maintained by
 the people who actually *know* whats involved, so you don't have to.

 > Solutions that involve me doing an arbitrary and increasing amount of
 > hand-hacking on every release are right out.
 
 Reading diffs and finding out why things changed, and following
 conversations on Linux-kernel are the only way you'll know if
 something is relevant in other trees. If you've a robot that can
 do this, I'm all ears, as it could save me hours each day.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Disgusted with kbuild developers

[Rob Landley]

On Friday 15 February 2002 05:04 pm, Eric S. Raymond wrote:

> Solutions that involve me doing an arbitrary and increasing amount of
> hand-hacking on every release are right out.

Um, Eric?  Isn't that what being a maintainer basically means?

Okay, Linus's changes killed backwards compatability with 2.4.  (He does 
that.  That's what 2.5 is for.  It would be nice if less of it happened in 
the stable series, but... :)

A maintainer is basically there to serve Linus (the project's undisputed 
architect), who periodically makes the architectural decision to break 
backwards compatability on some front.

You wanted to remain 2.4 help file maintainer as well as 2.5, and Linus did 
not address this concern (for whatever reason: Linus blackholing email as a 
way of disagreeing with it led to a lot of miscommunications like this one.)  
Fine.  Water under the bridge.  Linus made an architectural decision, and it 
has been implemented.  If it means you can't maintain 2.4 anymore, the sane 
move is to drop 2.4 (which you did) and move on.

That is why this is a dead issue, and bringing it up again doesn't serve as 
much purpose as you think it does.  (If you want to highlight the 
blackhole-related miscommunication, fine.  But even implying Linus's 
architectural decision was wrong carries no weight with your audience.)

> If you think this problem through, I'm sure you'll come up with a
> design very similar to what I actually built.  Which, by Linus's
> choice, got irrecoverably nuked.

Tough.

Eric, I like you and I still don't agree with you on this one.

First of all, the help files really are largely orthogonal to CML2.  They 
could be written in gzipped ebcdic.  Make a filter, read them, move on.  You 
are pointelessly wasting brownie points on a dead side issue.

Secondly, please define the problem space you're going after.  (I think that 
the main objection people have to this tool, they don't agree with the 
definition of the problem you're trying to solve.)

If you want CML2 is to be the best configure tool for the 2.5 (and later) 
kernel series, fine.  Then FOCUS ON THAT PROBLEM.

Overhead to deal with 2.4 is bloat.  Flexibility for projects outside of the 
kernel itself is a side issue.  Aunt Tillie is NOT the initial target 
audience.  Usage to configure debian userspace or some such is completely 
tangential.  All of the above may be fun, but they do not serve to advance 
the primary objective, and bringing them up does not help make a case for 
CML2.

Back up a bit.  What would be the most minimal, stripped-down version of CML2 
you could write?  No eye candy, no complications, no autoconfigurator, no 
tree view, no frozen symbols.  Just solving the core problem of configuring 
2.5 in a more flexible and less buggy way than CML1, with the three 
interfaces (oldconfig, menuconfig, xconfig) we've got now.

Think about that for a while.  Try to get THAT into the kernel.  THEN worry 
about building on top of that.

Remember: Linus likes small patches.  (CONCEPTUALLY small if possible, not 
just lines of code...)

Rob

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Rob Landley <landley@trommello.org>:
> On Friday 15 February 2002 05:04 pm, Eric S. Raymond wrote:
> 
> > Solutions that involve me doing an arbitrary and increasing amount of
> > hand-hacking on every release are right out.
> 
> Um, Eric?  Isn't that what being a maintainer basically means?

The problem isn't that I'm not willing to work hard. I am.  It's that
the level of handhacking has to be controlled below the threshold that
makes it impossible.

> Back up a bit.  What would be the most minimal, stripped-down version of CML2
> you could write?  No eye candy, no complications, no autoconfigurator, no 
> tree view, no frozen symbols.  Just solving the core problem of configuring 
> 2.5 in a more flexible and less buggy way than CML1, with the three 
> interfaces (oldconfig, menuconfig, xconfig) we've got now.

The big problem isn't the code transition.  It's the rulebase transition.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Rob Landley]

On Saturday 16 February 2002 01:35 am, Eric S. Raymond wrote:
> Rob Landley <landley@trommello.org>:
> > On Friday 15 February 2002 05:04 pm, Eric S. Raymond wrote:
> > > Solutions that involve me doing an arbitrary and increasing amount of
> > > hand-hacking on every release are right out.
> >
> > Um, Eric?  Isn't that what being a maintainer basically means?
>
> The problem isn't that I'm not willing to work hard. I am.  It's that
> the level of handhacking has to be controlled below the threshold that
> makes it impossible.

That's still not the point.  You had great tools to do a job Linus -wasn't 
interested in having done-.  Unsuprisingly, Linus broke them.  Linus wasn't 
trying to make more work for you as 2.5 help file maintainer, he simply 
didn't care about side projects outside of 2.5.

It's still a question of defining the work you're expected to do.  Keeping 
2.4 and 2.5 in sync was a job you invented.  Initially it was easy, later it 
stopped being easy, and eventually it became a very hard problem indeed to 
the point where you had to stop doing it.  But the dependency between the 2.4 
and 2.5 help files was always completely artificial.  That you thought 
maintaining it was expected of you all along was an honest miscommunication, 
but that's water under the bridge now.

> > Back up a bit.  What would be the most minimal, stripped-down version of
> > CML2 you could write?  No eye candy, no complications, no
> > autoconfigurator, no tree view, no frozen symbols.  Just solving the core
> > problem of configuring 2.5 in a more flexible and less buggy way than
> > CML1, with the three interfaces (oldconfig, menuconfig, xconfig) we've
> > got now.
>
> The big problem isn't the code transition.  It's the rulebase transition.

Then why confuse the two?

Eric, "make menuconfig" is now green text on a black background.  The old one 
was black and yellow text on grey boxes with a blue border.  They look 
NOTHING alike.  The tab-through buttons at the bottom have gone away, the 
list now takes up the whole screen horizontally and vertically instead of 
being confined to a curses box, and the rest of the keys you use to do stuff 
are different.  (q does nothing in the old menuconfig, x gives you the option 
to abort, and cursor left and right changes which button is highlighted.  
Looking back, yes "?" pulls up help in CML1 but I didn't need to know that.  
I never used it, I always tabbed over to "help" and hit enter.  And I never 
used "x" to exit, I tabbed over to the "exit" button and used it until I got 
out of the top level menu.  It's all I ever needed to know to make it work...)

I personally don't care about the other configurators since the only one I 
ever use is menuconfig.  And after using CML2 for a while, I'll even grant 
that the old CML1 interface was clunky and the new one is probably an 
improvement.  But that's not the POINT.

It IS a different interface.  For no apparent reason except that you don't 
want to implement the old one.  Pull them up side by side in two different 
windows and try to do the same config in paralell.  The difference is pretty 
darn obvious.

Remember when I asked for a blank line at the top of menuconfig and you went 
"no, that's a waste of screen space" and refused to even consider it?  We 
went back and forth for ten minutes on this issue.  Look at how MUCH of the 
old menuconfig is wasted in drawing boxes and drop shadows: there's only ten 
lines of actual menu.  (Your code doesn't have any blank lines in it either.  
Mine does.  Does this sound like a coding style flame war to you?  Do you see 
how it's an issue on which a judgement call from you might not suddenly 
resolve all debate?)

Your aesthetic judgement of how the interface should look is not the point.  
Can you or can you not make one that looks and acts like the old one?  Yes or 
no?  (Yes it IS a trivial problem relative to the rest of the codebase, but 
it's one that hasn't been addressed.  And considering the UI is what people 
actually see, and it's different, you're giving a horrible first impression 
on the compatability front.)

I don't care if it's "better".  New Coke was "better".  It won all the blind 
taste tests hands down.  The fact CML2 asks the same questions and produces 
exactly the same .config files as the old rulebase is a blind taste test 
issue.  In real life, people aren't blindfolded, and the first thing they're 
seeing is a profoundly different user interface, for no readily apparent 
reason except that you don't like the old one.

Change the colors.  Put in the tabbable buttons.  Waste over half the 
screen space with boxes and drop shadows.  Suppress your gag reflex.  Prove 
it can be done.  Feel free to keep the old green menuconfig in the separate 
tarball with the autoconfigurator and call it "mconfig" or something, just 
try to make it so that when a developer runs "make menuconfig" they can't 
TELL whether they're running cml1 or cml2 (unless a difference they bump into 
is a REALLY obvious and justifiable no-brainer bugfix, like the stupid ).  
And the same for oldconfig and xconfig.  -THAT- is far more likely to get 
merged.

Yes this IS a showstopper issue.  Really.  Honest.  Stop giving objectors 
such an amazingly obvious target...

Rob

Re: Disgusted with kbuild developers

[David Woodhouse]

esr@thyrsus.com said:
>  The big problem isn't the code transition.  It's the rulebase
> transition.

Only because you make it so.

I have no objection to the CML2 language and tools.

I've never done much more than glance at the CML1 mechanism, and as long as 
"$EDITOR .config && make oldconfig" continues to work as expected I doubt 
I'd ever pay any more attention to CML2. 

I am aware that CML2 should allow me to more accurately represent some
things that CML1 couldn't, and I would welcome that.

However - the thing to which I and many others object most strongly is the 
rulebase policy changes which appear to be inseparable from the change in 
mechanism. That is; we've tried to get you to separate them, and failed.

As you keep saying, CML1 is a very limited language. If CML2 cannot even
represent the _existing_ CML1 ruleset, then I think you need to go back to
the drawing board. 

I, for one, will have no objection to a merge of CML2 with an automated 
translation of the CML1 rules. You can 'improve' the rulebase later, at 
which point each change you want to make can be given individual attention.

You've said before that an automated translation is impossible. That's not 
our problem - it's yours. Fix the CML2 language so it _is_ possible. If that 
means adding ugly hacks to make it work, so be it - do it in the 
expectation that you can fix the rulebase later and remove them again.

Eric, you have demonstrated repeatedly that your taste w.r.t the
configuration rules is extremely, erm, 'different' from that of the majority
of developers. I find it difficult to believe that a self-proclaimed
'hacker of social systems' cannot comprehend the need to strictly separate
the mechanism changes from the controversial rulebase changes.

--
dwmw2

Re: Disgusted with kbuild developers

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> However - the thing to which I and many others object most strongly is the 
> rulebase policy changes which appear to be inseparable from the change in 
> mechanism. That is; we've tried to get you to separate them, and failed.

Failed?  Hardly.

The only rulebase policy change Tom Rini was able to identify in a recent
review was the magic behavior of EXPERT with respect to entries without
help.  Which I then removed by commenting out a single declaration.

There is a widespread myth that the CML2 rulebase is lousy with "policy
changes".  I don't know how it got started, but it needs to die now.

Maybe I need to write a CML2 FAQ.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Adam Kropelin]

----- Original Message -----
From: "Eric S. Raymond" <esr@thyrsus.com>
To: "David Woodhouse" <dwmw2@infradead.org>
Cc: "Rob Landley" <landley@trommello.org>; "Dave Jones" <davej@suse.de>; "Larry
McVoy" <lm@work.bitmover.com>; "Arjan van de Ven" <arjan@redhat.com>;
<linux-kernel@vger.kernel.org>
Sent: Saturday, February 16, 2002 8:57 AM
Subject: Re: Disgusted with kbuild developers


> David Woodhouse <dwmw2@infradead.org>:
> > However - the thing to which I and many others object most strongly is the
> > rulebase policy changes which appear to be inseparable from the change in
> > mechanism. That is; we've tried to get you to separate them, and failed.
>
> Failed?  Hardly.
>
> The only rulebase policy change Tom Rini was able to identify in a recent
> review was the magic behavior of EXPERT with respect to entries without
> help.  Which I then removed by commenting out a single declaration.
>
> There is a widespread myth that the CML2 rulebase is lousy with "policy
> changes".  I don't know how it got started, but it needs to die now.

The last time I played with CML2 (~2 months ago) I didn't even make it through a
full 'make config' before I had to stop on account of nausea. It was seemingly
overrun with gratuitous changes that were (to me, anyway) useless and annoying.

Examples:
* It started asking me vague questions like how old my computer was in order to
draw some magic conclusion about my configuration needs. *I* know my hardware.
Don't waste my time with Aunt Tillie questions that will quite possibly draw the
wrong conclusion for my needs.

* The 'make config' UI was subtly changed from the CML1 version. Why? I haven't
seen any complaints on the list about the UI.

* The 'make menuconfig' UI was significantly changed. Again, why? Haven't seen
any complaints about the old one.

Maybe these issues don't qualify as "policy change" but it seems obvious that
there is some other agenda being followed here besides replacing the CML1
language with one that can accurately represent the rulebase. I'm in favor of
the later, but definitely not if it comes inseparably packaged with the former.

--Adam

Re: Disgusted with kbuild developers

[David Woodhouse]

esr@thyrsus.com said:
> David Woodhouse <dwmw2@infradead.org>:
> > However - the thing to which I and many others object most strongly is the 
> > rulebase policy changes which appear to be inseparable from the change in 
> > mechanism. That is; we've tried to get you to separate them, and failed.

> Failed?  Hardly.

> The only rulebase policy change Tom Rini was able to identify in a
> recent review was the magic behavior of EXPERT with respect to entries
> without help.  Which I then removed by commenting out a single
> declaration.

> There is a widespread myth that the CML2 rulebase is lousy with
> "policy changes".  I don't know how it got started, but it needs to
> die now. 

Each time I've even glanced at it, I've seen bogus changes. I haven't 
looked at it recently, so cannot refute your statement that they are now 
all gone. You'll forgive me if I take your assertion with a pinch of salt, 
though?

A good way to kill this myth, if myth it is, would be to set up a test 
suite, as I suggested before. You already have a 'randomconfig' for CML2, I 
believe? I think there's also one for CML1.

Repeatedly make a random config (for a random architecture), with either
CML1 or CML2. Make oldconfig with the other CML, then with the first again.
If there are any differences between the original randomconfig output and
the output after the two 'oldconfig' stages, you've hit something that may
be a problem. 

Every time you hit such a difference, either fix it or document it and 
justify it. Ensure that the list of such justifications required is small, 
in order to improve the chance of CML2 being accepted. 

You are permitted to fix these differences by modifications to the CML1 
rules. The only cases where you should accept differences are where the 
CML1 behaviour does not accurately represent the intention of the 
developer, the developer has agreed with you, _and_ CML2 cannot implement 
the same buggy behaviour.

Note the third condition there. If CML2 _can_ implement the buggy CML1 
behaviour, do so -- you can fix the rules _later_. 




--
dwmw2

Re: Disgusted with kbuild developers

[Eric S. Raymond]

David Woodhouse <dwmw2@infradead.org>:
> A good way to kill this myth, if myth it is, would be to set up a test 
> suite, as I suggested before. You already have a 'randomconfig' for CML2, I 
> believe? I think there's also one for CML1.

There is no randomconfig for CML2.
 
> Repeatedly make a random config (for a random architecture), with either
> CML1 or CML2. Make oldconfig with the other CML, then with the first again.
> If there are any differences between the original randomconfig output and
> the output after the two 'oldconfig' stages, you've hit something that may
> be a problem. 
> 
> Every time you hit such a difference, either fix it or document it and 
> justify it. Ensure that the list of such justifications required is small, 
> in order to improve the chance of CML2 being accepted. 

This cycle is what I've been going through with a lot of my beta testers.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Jeff Garzik]

"Eric S. Raymond" wrote:
> 
> Dave Jones <davej@suse.de>:
> >  As you obviously completely ignored my previous point, I'll reiterate it.
> >
> >  1. You run Linus' split-into-config.in script on a 2.4 tree.
> >  2. You add whatever Config.ins have been updated to the 2.4 config.ins
> >  3. You regenerate with the find example I showed in the other mail.
> >
> >  There. 2.4 Configure.help up to date with latest symbols, but
> >  containing none of the 2.5 ones.
> 
> And you've completely ignored the real problem...which is when I get
> a text change for one tree, *how do I automatically propagate it to
> the other*?  How do I *tell* that it ought to be propagated?

It's easy as hell to propagate a Config[ure].help change across trees. 
Linus even gave you the code to do it, when he split up Configure.help.

Configure.help is nothing but a database, with two different but
easy-to-parse formats in 2.4 and 2.5.


> Solutions that involve me doing an arbitrary and increasing amount of
> hand-hacking on every release are right out.

If you are hand-hacking Config[ure].help changes, you are wasting a lot
of time...

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: Disgusted with kbuild developers

[Richard Gooch]

Eric S. Raymond writes:
> So I'd have to generate a custom version for him.  I used to have the
> machinery to do that by parsing magic comments in my master file.  
> Until Linus blew it apart.

Repeat after me: Linus is a bastard. Linus doesn't care.

Everyone knows this. Even Linus admits he's a bastard. We all have to
live with changes. It's frustrating when some code you're maintaining
code for different kernel trees and you can't share a common master
due to API changes. But Linus doesn't care. This is the price of doing
business here. Everyone knows that. And (almost) everyone keeps coming
back for more punishment. People live with the system.

So, can we please drop this thread? You're frustrated. Fine. You've
had your chance to vent. OK. Everybody needs to do that from time to
time.  But move on. Don't keep flogging this dead horse. You're
cutting into the bone, now.

				Regards,

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

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Richard Gooch <rgooch@ras.ucalgary.ca>:
> Repeat after me: Linus is a bastard. Linus doesn't care.

Fine.  We all know Linus is a bastard. 

If that's so, then why are the likes of Jeff Garzik and Al Viro 
spending so much effort trying to make *me* into the bad guy?

Time for somebody to up Jeff's Thorazine dosage...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Dave Jones]

On Fri, Feb 15, 2002 at 04:50:29PM -0500, Eric S. Raymond wrote:
 > If that's so, then why are the likes of Jeff Garzik and Al Viro 
 > spending so much effort trying to make *me* into the bad guy?

 'the bad guy' probably isn't the right choice of words.
 The point being made is that you constantly refuse to listen.
 You ask for an opinion, and when something comes back that isn't
 what you expect, you run off and write something completely 
 different just to appease some fabled Aunt Tilley, then come
 back and say "Ok, how about now?".

 CML2 seems to have all these wonderous features to make end-users
 happy. In writing these, you've shifted target audience from
 kernel _developers_ to kernel _users_.  Concerns from developers
 were constantly ignored in favour of adding extra candy.
 And you wonder why developers don't want to read about CML2 any more?

 You know, for all its glorious features, I'd not be surprised
 to see mconfig or some other 'improved CML1' end up in 2.6
 rather than CML2.

 > Time for somebody to up Jeff's Thorazine dosage...

 Increased dosages of something all around wouldn't go amiss I think.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Dave Jones <davej@suse.de>:
>  The point being made is that you constantly refuse to listen.
>  You ask for an opinion, and when something comes back that isn't
>  what you expect, you run off and write something completely 
>  different just to appease some fabled Aunt Tilley, then come
>  back and say "Ok, how about now?".

I honestly don't undestand how this myth got started, Dave.

>From my point of view, I have been busting my ass trying to *extract*
requirements from Linus and other people with a stake.  What guidance
I get is vague and contradictory.  My proposals to address it get ignored.
Everything I do right gets written off and teensy side issues get 
inflated into monsters.

It's utterly maddening to hear people accuse me of not listening when
I spend so damn much effort trying to do what they want for so little
reward...
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Nicolas Pitre]

On Fri, 15 Feb 2002, Eric S. Raymond wrote:

> Dave Jones <davej@suse.de>:
> >  The point being made is that you constantly refuse to listen.
> >  You ask for an opinion, and when something comes back that isn't
> >  what you expect, you run off and write something completely 
> >  different just to appease some fabled Aunt Tilley, then come
> >  back and say "Ok, how about now?".
> 
> I honestly don't undestand how this myth got started, Dave.
> 
> >From my point of view, I have been busting my ass trying to *extract*
> requirements from Linus and other people with a stake.  What guidance
> I get is vague and contradictory.  My proposals to address it get ignored.
> Everything I do right gets written off and teensy side issues get 
> inflated into monsters.
> 
> It's utterly maddening to hear people accuse me of not listening when
> I spend so damn much effort trying to do what they want for so little
> reward...

Eric....

Again...  Just like I said to you in private email...

Show us that you're able to write a 1 for 1 functional correspondance
between CML1 and CML2 and propose that for inclusion into 2.5.  This will
already have the advantage of using a common engine to parse the config
language regardless of the frontend used, along with the readability and
compactness of CML2.  This should not cause a too big cultural change.

Wait for a month or two while developers get used to it.  Then and only then
could you start discussion about advanced CML2 possibilities and features.  
REmember that Linux development only works like a car that you propose
individual parts individually and let people comment on them.  Providing the
whole car already assembled with a "turn key"  package simply doesn't work
with most car hackers.

As a bonus to further stimulate acceptance of CML2, make it work with the
tools that most people already have i.e. Python 1.5.


Nicolas

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Nicolas Pitre <nico@cam.org>:
> Show us that you're able to write a 1 for 1 functional correspondance
> between CML1 and CML2 and propose that for inclusion into 2.5.

This requirement is absurd.  When someone designs a new VM, we
don't demand that it crash or lock up the system in exactly the same
way that the old one did before it can go into the kernel.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Nicolas Pitre]

On Sat, 16 Feb 2002, Eric S. Raymond wrote:

> Nicolas Pitre <nico@cam.org>:
> > Show us that you're able to write a 1 for 1 functional correspondance
> > between CML1 and CML2 and propose that for inclusion into 2.5.
> 
> This requirement is absurd.  When someone designs a new VM, we
> don't demand that it crash or lock up the system in exactly the same
> way that the old one did before it can go into the kernel.

When someone design a new VM, and decides that it must be written in a 
totally new language with a new compiler, that someone will certainly face 
big resistance unless it can be proven that the new language can do exactly 
the same as the old one so other developers can get used to it first... 
especially if the old VM doesn't crash the system that often or maybe never 
for many users.

So yes, it might look absurd from your point of view but it's not for most
people not familiar with CML2.  And if that's what most of your opponants
are asking for why don't you give them just that?  Prove them that you're 
able to _split_ the concepts apart i.e. first the language vocabulary and 
tools, then the improved grammar, then the advanced configuration features, 
then the ultimate philosophical changes, etc.

Wake up Eric!

If people want A, B, C, agree somewhat with D, but have problems with E, do 
you realise that they will reject the whole thing at once if the only way 
you can present things is by submiting ABCDEFG indistinguishly?

Do things in steps.  First the struct translation of CML1 into CML2 with the 
new coherent frontends.  That's it.  If you can't do that then give up now 
and don't spent more time on CML2 because it will never go anywhere as the 
Linux kernel is concerned.


Nicolas

Re: Disgusted with kbuild developers

[Felix von Leitner]

Thus spake Nicolas Pitre (nico@cam.org):
> As a bonus to further stimulate acceptance of CML2, make it work with the
> tools that most people already have i.e. Python 1.5.

I don't have python.  Any version of python.

And I refuse to use software that forces me to install an ugly
monstrosity like python.  Integrating python in the build process is
like integrating IE into Windows.  It may please the stupid masses who
use Red Hat anyway and don't care what happens when they click their
mouse button, but it's conceptually bad for the OS and the kernel so far
went to great lengths to not depend on external bloat.  It is a good
thing to minimize dependencies!  If you can't do it in C and /bin/sh,
then please step aside and let someone handle the job who is up to it.

So far this looks like you are on one hell of an ego trip.

Felix

Re: Disgusted with kbuild developers

[Larry McVoy]

On Fri, Feb 15, 2002 at 04:50:29PM -0500, Eric S. Raymond wrote:
> Richard Gooch <rgooch@ras.ucalgary.ca>:
> > Repeat after me: Linus is a bastard. Linus doesn't care.
> 
> Fine.  We all know Linus is a bastard. 
> 
> If that's so, then why are the likes of Jeff Garzik and Al Viro 
> spending so much effort trying to make *me* into the bad guy?

Perhaps they don't like the results of your efforts and they resent what
they perceive to be end runs around the normal process of getting changes
accepted.  As well they should.  Your attempt to avoid peer review is 
disgusting, it's the worst of what happens in closed source shops when
marketing forces the wrong answer in over the objections of the people
who have to live with it.  Yuck.

If you really want to contribute, what you'll do is improve the existing
system.  Screaming that it can't be done just means you aren't a kernel
programmer.  What kernel programmers do is the hard ugly work it takes to
make things work smoothly.  Look at any device driver - just a handfull
of simple interfaces: open,close,read,write,ioctl (ok that last one is
far from simple).  Now go look at the code implementing those interfaces,
it's frequently a huge effort to make some recalcitrant device behave.

But that's what kernel programmers do.  They take a mess and present
a clean, well working system.  No one said it was easy.  If you are a
kernel programmer, you can take CML1 and make it work, for a reasonable
definition of "work".  If you can't, you're far better off to admit
you're in over your head and give it up.  Harping on CML2 as the better
answer isn't going to work.  Neither is telling people they don't get it,
when those same people have done 10,000 times more work on the kernel
than you'll ever do.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Larry McVoy <lm@bitmover.com>:
> Perhaps they don't like the results of your efforts and they resent what
> they perceive to be end runs around the normal process of getting changes
> accepted.  As well they should.  Your attempt to avoid peer review is 
                                                   ^^^^^^^^^^^^^^^^^
> disgusting, it's the worst of what happens in closed source shops when
> marketing forces the wrong answer in over the objections of the people
> who have to live with it.  Yuck.

I've "avoided peer review" really effectively, yeah.  Unanimous support
from the kbuild team.  Three other projects using the software.  Dozens
of beta testers.  Nope, no review at all there.  Ain't I clever?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Matthias Andree]

On Fri, 15 Feb 2002, Larry McVoy wrote:

> If you really want to contribute, what you'll do is improve the existing
> system.  Screaming that it can't be done just means you aren't a kernel
> programmer.  What kernel programmers do is the hard ugly work it takes to
> make things work smoothly.  Look at any device driver - just a handfull
> of simple interfaces: open,close,read,write,ioctl (ok that last one is
> far from simple).  Now go look at the code implementing those interfaces,
> it's frequently a huge effort to make some recalcitrant device behave.
> 
> But that's what kernel programmers do.  They take a mess and present
> a clean, well working system.  No one said it was easy.  If you are a
> kernel programmer, you can take CML1 and make it work, for a reasonable
> definition of "work".  If you can't, you're far better off to admit
> you're in over your head and give it up.  Harping on CML2 as the better
> answer isn't going to work.  Neither is telling people they don't get it,
> when those same people have done 10,000 times more work on the kernel
> than you'll ever do.  

(cc: list killed, I assume all are subscribed to l-k)

Preface: I have no plan of kbuild and kernel configuration, so take this
with a grain of salt. But maybe it gives me the chance to calm all this
because I'm not biased towards either side.

Are you telling that kernel programmers don't rewrite code from scratch?
Is that a correct interpretation of "improve the existing system"? Note
that "it can't be done" can also imply "cannot reasonable be done".

If that's not what you mean, stop reading this mail, drop a line to
clarify this and forget this piece of mail. If it _is_ what you mean,
then with all due respect, why cannot kernel programmers rewrite a
subsystem (even if it interfaces with the whole world of kernel
configurations) from scratch?

Eric has done it, without being of kernel hacker temple's fame.

Whether he doesn't listen to other developers, I cannot tell, I got my
/fetchmail/ issues resolved. Still, I share the opinion that the kernel
build stuff is mainly for developers (and if it cuts down turnaround
times, it well deserves a try), and if -- as a side effect -- it's good
for the user, so be it, and if it's clear and self documenting, that's
nothing a developer would reject. Resurrecting this IMHO dead thread
around Mrs. Tillie won't bring any good. (Although Aunt Tillie should
really get her kernel as .deb or .rpm.)

AFAICS, Eric has gone lengths to get a competitive kernel configuration
system working well enough for production use, minor issues seem to
remain, like split Configure.help. I can easily understand no-one is
throwing this work away. If he's convinced the system is more consistent
and robust in itself, that's good -- but all this advocacy seems to be
torn down to some (personal) vendetta. Linux does not deserve that.

What I'm missing in this thread are facts. The point "communications
problem" has been raised. It seems to me as though the two opposing
parties (pro and con CML2) were not clear about what they expect from
the other party. If something has gone on behind the scenes, well, I
will have missed it...

I'm really hoping that this issue can get resolved in one way or
another, my personal opinion is that one single config stuff parser is
the goal, be it mconfig or be it CML2.

Re: Disgusted with kbuild developers

[Dave Jones]

On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
 > Are you telling that kernel programmers don't rewrite code from scratch?
 > Is that a correct interpretation of "improve the existing system"? Note
 > that "it can't be done" can also imply "cannot reasonable be done".
 > Eric has done it, without being of kernel hacker temple's fame.

 The kernel hacker approach: Gradual change toward a predefined goal.
 The Eric approach: Rip out existing, replace with new.

 If Al Viro can rewrite the guts of the VFS without hardly anyone
 noticing any disturbance, and the configuration system can't be
 done this way, something is amiss.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Disgusted with kbuild developers

[David Lang]

by the way folks, unless Eric is plain lying to us the 'private flamewar'
that Linus has with someone that prompted him to splitup the config.help
stuff was not with Eric.

David Lang


On Sat, 16 Feb 2002, Dave Jones wrote:

> Date: Sat, 16 Feb 2002 00:29:59 +0100
> From: Dave Jones <davej@suse.de>
> To: linux-kernel@vger.kernel.org
> Subject: Re: Disgusted with kbuild developers
>
> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
>  > Are you telling that kernel programmers don't rewrite code from scratch?
>  > Is that a correct interpretation of "improve the existing system"? Note
>  > that "it can't be done" can also imply "cannot reasonable be done".
>  > Eric has done it, without being of kernel hacker temple's fame.
>
>  The kernel hacker approach: Gradual change toward a predefined goal.
>  The Eric approach: Rip out existing, replace with new.
>
>  If Al Viro can rewrite the guts of the VFS without hardly anyone
>  noticing any disturbance, and the configuration system can't be
>  done this way, something is amiss.
>
> --
> | Dave Jones.        http://www.codemonkey.org.uk
> | SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Disgusted with kbuild developers

[Matthias Andree]

On Sat, 16 Feb 2002, Dave Jones wrote:

> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
>  > Are you telling that kernel programmers don't rewrite code from scratch?
>  > Is that a correct interpretation of "improve the existing system"? Note
>  > that "it can't be done" can also imply "cannot reasonable be done".
>  > Eric has done it, without being of kernel hacker temple's fame.
> 
>  The kernel hacker approach: Gradual change toward a predefined goal.
>  The Eric approach: Rip out existing, replace with new.
> 
>  If Al Viro can rewrite the guts of the VFS without hardly anyone
>  noticing any disturbance, and the configuration system can't be
>  done this way, something is amiss.

Not necessarily. If the gradual change infers intermediate functions
that are not needed for a hard cut-over, it's no good to do all the
extra work if the already-existing result is known to work. I'd
certainly not drop CML1 from 2.4, but 2.5 is the time for changes.

You don't take an airplane to drive alongs autobahns for a gradual
change either.

It seems to me as though the "rip out existing" issue was rather a
"don't let us maintain two parts of the same type at the same time"
convenience feature than a trait of CML2, and if so, keep both for some
releases and drop CML1 in, say, 2.5.8.

Re: Disgusted with kbuild developers

[Larry McVoy]

On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> Are you telling that kernel programmers don't rewrite code from scratch?
> Is that a correct interpretation of "improve the existing system"? Note
> that "it can't be done" can also imply "cannot reasonable be done".
> 
> If that's not what you mean, stop reading this mail, drop a line to
> clarify this and forget this piece of mail.

That's not what I mean.  But it's worthwhile to note that almost all
"rewrite from scratch" projects really translate into "I'm unwilling to
learn what the last guy did, and I'm smarter, so I'm going to do what
I want to do".  And that is not what kernel programmers do.  They would
love to be able to do that but it's very rare that doing so makes sense.

In reality, the guy who came before you wasn't an idiot.  Maybe s/he
didn't do the best job possible, but the fact that the code is there and
works implies some level of understanding.  Real programmers make their
work fit *seamlessly* with the work of the people who came before them.
It's egoless programming, you are striving to make things fit so well
that noone can see where person A stopped and person B started.

In Eric's case, it would have been far better if he had done some work
to make CML1 work better.  It simply isn't broken enough to justify
throwing it out.  And it's not at all clear to me, at least, that the
CML2 stuff is any less broken, it's just broken in different ways.
Unless Eric can make a system that is widely viewed as better overall
than CML1, making one that is better in some ways but worse or just as
bad in others, well, that's a big waste of time.

At Sun, we had a rule that a major change was automatically disallowed
unless it showed a factor of 2 improvement in some important way while
holding the other variables constant.  I don't think CML2 would pass
that test.  Aunt Tillie's opinion doesn't count.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Disgusted with kbuild developers

[David Lang]

I wasn't at the kernel summit meeting, but my undersanding from the
'press' reports was that it was the CML1 guys who said they wanted to
throw it out and start from scratch. I don't know what role Eric had in
the discussion, but it sure didn't sound like it was him alone prompting
the change.

David Lang


On Fri, 15 Feb 2002, Larry McVoy wrote:

> Date: Fri, 15 Feb 2002 15:36:36 -0800
> From: Larry McVoy <lm@bitmover.com>
> To: linux-kernel@vger.kernel.org
> Subject: Re: Disgusted with kbuild developers
>
> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> > Are you telling that kernel programmers don't rewrite code from scratch?
> > Is that a correct interpretation of "improve the existing system"? Note
> > that "it can't be done" can also imply "cannot reasonable be done".
> >
> > If that's not what you mean, stop reading this mail, drop a line to
> > clarify this and forget this piece of mail.
>
> That's not what I mean.  But it's worthwhile to note that almost all
> "rewrite from scratch" projects really translate into "I'm unwilling to
> learn what the last guy did, and I'm smarter, so I'm going to do what
> I want to do".  And that is not what kernel programmers do.  They would
> love to be able to do that but it's very rare that doing so makes sense.
>
> In reality, the guy who came before you wasn't an idiot.  Maybe s/he
> didn't do the best job possible, but the fact that the code is there and
> works implies some level of understanding.  Real programmers make their
> work fit *seamlessly* with the work of the people who came before them.
> It's egoless programming, you are striving to make things fit so well
> that noone can see where person A stopped and person B started.
>
> In Eric's case, it would have been far better if he had done some work
> to make CML1 work better.  It simply isn't broken enough to justify
> throwing it out.  And it's not at all clear to me, at least, that the
> CML2 stuff is any less broken, it's just broken in different ways.
> Unless Eric can make a system that is widely viewed as better overall
> than CML1, making one that is better in some ways but worse or just as
> bad in others, well, that's a big waste of time.
>
> At Sun, we had a rule that a major change was automatically disallowed
> unless it showed a factor of 2 improvement in some important way while
> holding the other variables constant.  I don't think CML2 would pass
> that test.  Aunt Tillie's opinion doesn't count.
> --
> ---
> Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Disgusted with kbuild developers

[Alan Cox]

> 'press' reports was that it was the CML1 guys who said they wanted to
> throw it out and start from scratch. I don't know what role Eric had in
> the discussion, but it sure didn't sound like it was him alone prompting
> the change.

I was at the summit but I guess I missed any real discussion on it, other
than the out of meeting sequence with Linus basically yelling at Eric
over some CML2 stuff.

I still hold the opinion the CML1 declarations are sufficient, and that
mconfig is more than enough to do what we need, possibly coupled with
some automatic rule validation stuff.

Michael Chastain fixed the nasty parsing mess in 1998

Re: Disgusted with kbuild developers

[Ben Greear]

Larry McVoy wrote:

> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> 
>>Are you telling that kernel programmers don't rewrite code from scratch?
>>Is that a correct interpretation of "improve the existing system"? Note
>>that "it can't be done" can also imply "cannot reasonable be done".
>>
>>If that's not what you mean, stop reading this mail, drop a line to
>>clarify this and forget this piece of mail.
>>
> 
> That's not what I mean.  But it's worthwhile to note that almost all
> "rewrite from scratch" projects really translate into "I'm unwilling to
> learn what the last guy did, and I'm smarter, so I'm going to do what
> I want to do".  And that is not what kernel programmers do.  They would
> love to be able to do that but it's very rare that doing so makes sense.


I have to call bullshit on this one! :)

The kernel is always getting some module replaced by some other
module.  Everything from the VM to the recent ALSA merge that
will kill OSS.  This is not to claim it's always a good thing,
just that you can't claim this is not what kernel programmers do...

Hell, we gotta be some of the most egotistical folks around,
it's what keeps us going!



-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Disgusted with kbuild developers

[Rogier Wolff]

Larry McVoy wrote:
> On Sat, Feb 16, 2002 at 12:23:12AM +0100, Matthias Andree wrote:
> > Are you telling that kernel programmers don't rewrite code from scratch?
> > Is that a correct interpretation of "improve the existing system"? Note
> > that "it can't be done" can also imply "cannot reasonable be done".
> > 
> > If that's not what you mean, stop reading this mail, drop a line to
> > clarify this and forget this piece of mail.
> 
> That's not what I mean.  But it's worthwhile to note that almost all
> "rewrite from scratch" projects really translate into "I'm unwilling to
> learn what the last guy did, and I'm smarter, so I'm going to do what
> I want to do".  And that is not what kernel programmers do.  They would
> love to be able to do that but it's very rare that doing so makes sense.

Sometimes the "old" code is set up in such a way that the "right" way
to do it is not possible. That doesn't make the last guy "stupid": it
can be that when he did it, that was the right way to do things, but
that we've learned since then.

If the "cleanup" would result in changing more than say 60% of the
code, then a rewrite is in order. The old code is usually still in
place. That will allow you to "steal" code that is not the core of the
rewrite: just copy it.


I've heard that someone is trying to revolutionize "source code
control systems". He's rewriting almost everything, and not enhancing
any previous systems. What was his name again?

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: Disgusted with kbuild developers

[Larry McVoy]

On Mon, Feb 18, 2002 at 10:41:03AM +0100, Rogier Wolff wrote:
> Larry McVoy wrote:
> > That's not what I mean.  But it's worthwhile to note that almost all
> > "rewrite from scratch" projects really translate into "I'm unwilling to
> > learn what the last guy did, and I'm smarter, so I'm going to do what
> > I want to do".  And that is not what kernel programmers do.  They would
> > love to be able to do that but it's very rare that doing so makes sense.
> 
> Sometimes the "old" code is set up in such a way that the "right" way
> to do it is not possible. 

_Sometimes_ that is true.  But there is no way you are going to be able to
say that that is the typical case.  History says otherwise.  I'm not saying
that rewrites aren't necessary, I'm saying that many, maybe most, aren't
necessary.

> I've heard that someone is trying to revolutionize "source code
> control systems". He's rewriting almost everything, and not enhancing
> any previous systems. What was his name again?

The fact that BitKeeper will read and write 30 year old SCCS files
seems to have escaped your attention.  Contrast that with the CML
debate and I think it makes my point perfectly.  If Eric's changes
worked the same way, we'd have a system which worked on the old data
and the new.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Disgusted with kbuild developers

[Martin Dalecki]

Matthias Andree wrote:

>Eric has done it, without being of kernel hacker temple's fame.
>
>Whether he doesn't listen to other developers, I cannot tell, I got my
>/fetchmail/ issues resolved. Still, I share the opinion that the kernel
>
Fetchmail is a prime example for the fact that Eric isn't a capable 
software designer.
Yes it is usefull, and works, but the configuration doesn't solve the 
common problems
for which fetchmail is used in an easy way... I wouldn't like to have 
something like
fetchmail for the kernel configuration.

Re: Disgusted with kbuild developers

[Matthias Andree]

On Sat, 16 Feb 2002, Martin Dalecki wrote:

> Matthias Andree wrote:
> 
> >Eric has done it, without being of kernel hacker temple's fame.
> >
> >Whether he doesn't listen to other developers, I cannot tell, I got my
> >/fetchmail/ issues resolved. Still, I share the opinion that the kernel
> >
> Fetchmail is a prime example for the fact that Eric isn't a capable 
> software designer.
> Yes it is usefull, and works, but the configuration doesn't solve the 
> common problems
> for which fetchmail is used in an easy way... I wouldn't like to have 
> something like
> fetchmail for the kernel configuration.

The point is not to discuss fetchmail ease of use or design or whatever.
CML2 is much younger, and in a much more maintainable language (or so I
believe, at last; Python vs. C).

The point I'm raising is that I cannot believe Eric would not care for
change requests right now, that contradicts my experience.

-- 
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin

Re: Disgusted with kbuild developers

[Michal Jaegermann]

On Sat, Feb 16, 2002 at 02:04:14PM +0100, Matthias Andree wrote:
> 
> The point is not to discuss fetchmail ease of use or design or whatever.
> CML2 is much younger, and in a much more maintainable language (or so I
> believe, at last; Python vs. C).

I am not so convinced about this "much more" in practice.  As an
"interested observer", but not a Python programmer, I watch for quite a
while a set of programs written in Python which affect me directly;
namely Red Hat configuration/installation tools.  Literally for years
and many releases bombs and inscrutable Python tracebacks were the
constant element of this picture.  These tools, after an obvious and
long effort, are now finally in much better shape then they used to be
but bugs are regularly reintroduced with every change.

I do not think that this happens because Red Hat has lazy or incompetent
people but because these problems are hard and Python is quite far from
silver bullet and "sliced bread" its proponent wants us to believe.  I
rather suspect that all behind the scenes machinations by Python rather
mask difficulties and make harder to eradicte those bugs.

I also cannot help not to notice that the previous bit flare-up about
CML2 on lkml was quelled to a great extent when somebody annouced that
he is rewriting required tools in C.  I had an impression that most
people then shrugged "Ok, so Eric will prototope in whatever he feels
comfortable with, we will have something acceptable later and we will
see how this works".  Now it turns out the the project got abandoned so
a requirement for a huge blob of a language (as opposed to Python 1.5
which is quite smaller), which most developers do not have or need for
anything else, is still there.  Hm..., smells very backdoor even if
it was not intended that way. 

  Michal

Re: Disgusted with kbuild developers

[Matthias Andree]

On Sat, 16 Feb 2002, Michal Jaegermann wrote:

> I also cannot help not to notice that the previous bit flare-up about
> CML2 on lkml was quelled to a great extent when somebody annouced that
> he is rewriting required tools in C.  I had an impression that most
> people then shrugged "Ok, so Eric will prototope in whatever he feels
> comfortable with, we will have something acceptable later and we will
> see how this works".  Now it turns out the the project got abandoned so
> a requirement for a huge blob of a language (as opposed to Python 1.5
> which is quite smaller), which most developers do not have or need for
> anything else, is still there.  Hm..., smells very backdoor even if
> it was not intended that way. 

I recall there has been a complete patch set to make CML2 work with
Python 1.5.2, if the two (2) in "Python 2" is your concern. The archives
should tell us more.

(I'm not jumping into the other part of your mail on Python vs. Red Hat
configurator bugs because I don't know that particular tool and didn't
review its internal design.)

-- 
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin

Re: Disgusted with kbuild developers

[Alan Cox]

> If that's so, then why are the likes of Jeff Garzik and Al Viro 
> spending so much effort trying to make *me* into the bad guy?

I don't think they are. They are just watching you do it yourself

> Time for somebody to up Jeff's Thorazine dosage...

See...

Re: Disgusted with kbuild developers

[Alexander Viro]

On Fri, 15 Feb 2002, Eric S. Raymond wrote:

> Richard Gooch <rgooch@ras.ucalgary.ca>:
> > Repeat after me: Linus is a bastard. Linus doesn't care.
> 
> Fine.  We all know Linus is a bastard. 
> 
> If that's so, then why are the likes of Jeff Garzik and Al Viro 
> spending so much effort trying to make *me* into the bad guy?

I can't speak for Jeff.  Compared to me Linus is downright nice,
kind and touchy-feely guy.  I'm not.  I don't like manipulative
arseholes.  I _despise_ inept manipulative arseholes and I really
can't stand demagogy - what with a massive overdose of that in
school years (Soviet Union, early 80s - 'nuff said).

Your habit of claiming completely unsubstantiated credentials also
doesn't help.  Let me spell it out - your pseudo-phylosophical
essays are handwaving at best and deliberate dishonesty at worst.
If you expect respect for them - you are looking in the wrong
place.  You don't understand how kernel development works - that
much had been made obvious for everyone by the last couple of months.
And yet you don't hesitate to plug holes in your proposals with empty
preaching ex cathedra and massive demagogy.

I had seen such guys in Uni.  Usually they taught Marxism-Leninism,
History of Party, Philosophy, etc.  Nobody with a shred of clue and
self-respect had touched them with a ten-feet pole.  Excuse me for
being not too happy to see that type again.

Re: Disgusted with kbuild developers

[William Scott Lockwood III]

Here's an idea Al:  Put up, or shut up.  Where's your code to replace CML1
with?  I like Eric's system, and find it's MUCH more useful in a production
environment than CML1 was.  Where's your replacement idea?

Scott

----- Original Message -----
From: "Alexander Viro" <viro@math.psu.edu>
To: "Eric S. Raymond" <esr@thyrsus.com>
Cc: "Richard Gooch" <rgooch@ras.ucalgary.ca>; "Dave Jones" <davej@suse.de>;
"Larry McVoy" <lm@work.bitmover.com>; "Arjan van de Ven"
<arjan@pc1-camc5-0-cust78.cam.cable.ntl.com>; <linux-kernel@vger.kernel.org>
Sent: Friday, February 15, 2002 5:37 PM
Subject: Re: Disgusted with kbuild developers


>
>
> On Fri, 15 Feb 2002, Eric S. Raymond wrote:
>
> > Richard Gooch <rgooch@ras.ucalgary.ca>:
> > > Repeat after me: Linus is a bastard. Linus doesn't care.
> >
> > Fine.  We all know Linus is a bastard.
> >
> > If that's so, then why are the likes of Jeff Garzik and Al Viro
> > spending so much effort trying to make *me* into the bad guy?
>
> I can't speak for Jeff.  Compared to me Linus is downright nice,
> kind and touchy-feely guy.  I'm not.  I don't like manipulative
> arseholes.  I _despise_ inept manipulative arseholes and I really
> can't stand demagogy - what with a massive overdose of that in
> school years (Soviet Union, early 80s - 'nuff said).
>
> Your habit of claiming completely unsubstantiated credentials also
> doesn't help.  Let me spell it out - your pseudo-phylosophical
> essays are handwaving at best and deliberate dishonesty at worst.
> If you expect respect for them - you are looking in the wrong
> place.  You don't understand how kernel development works - that
> much had been made obvious for everyone by the last couple of months.
> And yet you don't hesitate to plug holes in your proposals with empty
> preaching ex cathedra and massive demagogy.
>
> I had seen such guys in Uni.  Usually they taught Marxism-Leninism,
> History of Party, Philosophy, etc.  Nobody with a shred of clue and
> self-respect had touched them with a ten-feet pole.  Excuse me for
> being not too happy to see that type again.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Disgusted with kbuild developers

[Larry McVoy]

On Fri, Feb 15, 2002 at 07:14:17PM -0600, William Scott Lockwood III wrote:
> Here's an idea Al:  Put up, or shut up.  Where's your code to replace CML1
> with?  I like Eric's system, and find it's MUCH more useful in a production
> environment than CML1 was.  Where's your replacement idea?

I think Al's work on the kernel speaks for itself.  He's been putting up
just fine, thank you.  And I think you're looking in the wrong place,
Al has expressed no interest (that I'm aware of) in rewriting this code.
As a user of the new system, a pretty typical user, his opinion counts.

I don't think that you're really getting the point.  Nobody is saying that
CML1 is the greatest thing since sliced bread.  What they are saying is that
it seems to work pretty well, yes it could be better, but CML2 isn't shaping
up to be an improvement so much as a Eric Raymond Language exercise.  Noone
begrudges Eric his right to come up with as many little languages as he wants.
But when he asks the kernel developers to use them, he'd better be prepared
to hear each and every thing they find wanting, and address the majority of
those issues.  That hasn't happened.  Instead, there have been a lot of 
flame wars, politics, protests about Linus, etc.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Disgusted with kbuild developers

[William Scott Lockwood III]

again, if you all would spend 1/10th of your time helping as opposed to just
slaming it, I'd be impressed.  CML2 makes a WORLD of difference for me
personally.  But hey, what do I know?  I'm just a network administrator, I'm
not a kernel wizard, so feel free to just totally disregard my opinions...

----- Original Message -----
From: "Larry McVoy" <lm@bitmover.com>
To: "William Scott Lockwood III" <thatlinuxguy@hotmail.com>
Cc: "Alexander Viro" <viro@math.psu.edu>; "Eric S. Raymond"
<esr@thyrsus.com>; <linux-kernel@vger.kernel.org>
Sent: Friday, February 15, 2002 7:59 PM
Subject: Re: Disgusted with kbuild developers


> On Fri, Feb 15, 2002 at 07:14:17PM -0600, William Scott Lockwood III
wrote:
> > Here's an idea Al:  Put up, or shut up.  Where's your code to replace
CML1
> > with?  I like Eric's system, and find it's MUCH more useful in a
production
> > environment than CML1 was.  Where's your replacement idea?
>
> I think Al's work on the kernel speaks for itself.  He's been putting up
> just fine, thank you.  And I think you're looking in the wrong place,
> Al has expressed no interest (that I'm aware of) in rewriting this code.
> As a user of the new system, a pretty typical user, his opinion counts.
>
> I don't think that you're really getting the point.  Nobody is saying that
> CML1 is the greatest thing since sliced bread.  What they are saying is
that
> it seems to work pretty well, yes it could be better, but CML2 isn't
shaping
> up to be an improvement so much as a Eric Raymond Language exercise.
Noone
> begrudges Eric his right to come up with as many little languages as he
wants.
> But when he asks the kernel developers to use them, he'd better be
prepared
> to hear each and every thing they find wanting, and address the majority
of
> those issues.  That hasn't happened.  Instead, there have been a lot of
> flame wars, politics, protests about Linus, etc.
> --
> ---
> Larry McVoy            lm at bitmover.com
http://www.bitmover.com/lm
>

Re: Disgusted with kbuild developers

[Daniel Phillips]

On February 16, 2002 03:08 am, William Scott Lockwood III wrote:
> again, if you all would spend 1/10th of your time helping as opposed to just
> slaming it, I'd be impressed.  CML2 makes a WORLD of difference for me
> personally.

Could you elaborate on that please?

> But hey, what do I know?  I'm just a network administrator, I'm
> not a kernel wizard, so feel free to just totally disregard my opinions...

-- 
Daniel

Re: Disgusted with kbuild developers

[John Jasen]

If Microsoft really wanted to kill open source, they'd put you all in the
same room together with weapons and tequila.

--
-- John E. Jasen (jjasen1@umbc.edu)
-- In theory, theory and practise are the same. In practise, they aren't.

Re: Disgusted with kbuild developers

[William Scott Lockwood III]

Also, it apears I am no longer getting messages from the list - thanks, whom
ever it was that killed me off the list.  So nice of you to do that.
----- Original Message -----
From: "John Jasen" <jjasen1@umbc.edu>
To: "Larry McVoy" <lm@bitmover.com>
Cc: "William Scott Lockwood III" <thatlinuxguy@hotmail.com>; "Alexander
Viro" <viro@math.psu.edu>; "Eric S. Raymond" <esr@thyrsus.com>;
<linux-kernel@vger.kernel.org>
Sent: Friday, February 15, 2002 10:17 PM
Subject: Re: Disgusted with kbuild developers


>
> If Microsoft really wanted to kill open source, they'd put you all in the
> same room together with weapons and tequila.
>
> --
> -- John E. Jasen (jjasen1@umbc.edu)
> -- In theory, theory and practise are the same. In practise, they aren't.
>
>

Re: Disgusted with kbuild developers

[yodaiken]

On Fri, Feb 15, 2002 at 03:09:25PM -0700, Richard Gooch wrote:
> Eric S. Raymond writes:
> > So I'd have to generate a custom version for him.  I used to have the
> > machinery to do that by parsing magic comments in my master file.  
> > Until Linus blew it apart.
> 
> Repeat after me: Linus is a bastard. Linus doesn't care.

And he owes me $5 which he won't pay 

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: Disgusted with kbuild developers

[Cort Dougan]

You're not going to get sympathy from this list for having your work "blown
apart" by Linus.  Fix the problems that are holding things up or give up on
it.  The current system, CML1, does function so you have to accept you're 
pushing CML2 up a hill.

} So I'd have to generate a custom version for him.  I used to have the
} machinery to do that by parsing magic comments in my master file.  
} Until Linus blew it apart.

Re: Disgusted with kbuild developers

[Jeff Garzik]

"Eric S. Raymond" wrote:
> Dave Jones <davej@suse.de>:
> >  find . -name Config.help -exec cat {} >Configure.help \;
> 
> Back-seat drivers.  Answers for everything, understanding of nothing.

Did you read this in _How to Win Friends And Influence People_?


> Sorry, it's not *nearly* that simple.  For one thing, one of the fourteen
> billion requirements I've had dropped on me is that Marcelo doesn't want
> any symbols in his help file that aren't actually in the 2.4 rulebase.
> 
> So I'd have to generate a custom version for him.  I used to have the
> machinery to do that by parsing magic comments in my master file.
> Until Linus blew it apart.

Linus also gave you C code which, slightly modified, could discern which
CONFIG_xxx help texts were needed for a given tree.

How hard is it to maintain a database where the key for each entry is
easy an unambigious?

	Jeff



-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> How hard is it to maintain a database where the key for each entry is
> easy an unambigious?

It's not that simple, either.  You have to track the symbols that are
*supposed* to be different between trees.  The devil is in the details --
and it's a big devil.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Alan Cox]

> It's not that simple, either.  You have to track the symbols that are
> *supposed* to be different between trees.  The devil is in the details --
> and it's a big devil.

(Not tested but something like this ought to split them neatly out of
 a master tree into the 2.4 format)

for i in $(find . -name "[Cc]onfig.in" -print)
do
	grep CONFIG_ '$i'
done | sort -u |
while read x
do
	grep -B1 -A200 '$x' MasterConfigHelpFile |
	( 
		read A
		read B
		cat > frob
	)
	ed frob << 'FOO'
	/^$
	.,$d
	wq
	'FOO' >/dev/null
	cat frob
done

Re: Disgusted with kbuild developers

[Robert Love]

On Fri, 2002-02-15 at 15:39, Eric S. Raymond wrote:

> As a result, I had to tell Marcelo I had no choice but to drop maintaining
> the 2.4 help file.  The divergence, and the damage, is probably not
> recoverable.

Divergence and damage to a configure help file ?

As someone who professes to be well-versed in social systems and their
associated mechanics, I am sure you understand the notions of social
contracts and the like.  Thus, if we, as the developers who actually
look at the Config.help, drop the changes then that is our problem.  And
if we don't care, then there must be nothing to care about.

If Marcelo and Linus are not begging for Configure.help updates (like I
beg for SCSI layer rewrites) then there is a reason.

	Robert Love

Re: Disgusted with kbuild developers

[That Linux Guy]

The amount of whining I've had to read today on this topic just astonishes
me.  People, please - devote 1/10th of the energy to helping esr finish and
fix CML2 to meet Linus' expectations.  Face the fact:  CML1 was good for
it's time, but that time is now gone.

If you spent as much time helping to get CML2 up and going as some of you
have trying to kill it (while not offering anything constructive to replace
it) it would have been DONE 6 months ago.

Sometimes, this list is worse than the proverbial sewing circle.

> > As a result, I had to tell Marcelo I had no choice but to drop
maintaining
> > the 2.4 help file.  The divergence, and the damage, is probably not
> > recoverable.
>
> Divergence and damage to a configure help file ?
>
> As someone who professes to be well-versed in social systems and their
> associated mechanics, I am sure you understand the notions of social
> contracts and the like.  Thus, if we, as the developers who actually
> look at the Config.help, drop the changes then that is our problem.  And
> if we don't care, then there must be nothing to care about.
>
> If Marcelo and Linus are not begging for Configure.help updates (like I
> beg for SCSI layer rewrites) then there is a reason.
>
> Robert Love
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Disgusted with kbuild developers

[Jeff Garzik]

That Linux Guy wrote:
> 
> The amount of whining I've had to read today on this topic just astonishes
> me.  People, please - devote 1/10th of the energy to helping esr finish and
> fix CML2 to meet Linus' expectations.  Face the fact:  CML1 was good for
> it's time, but that time is now gone.
> 
> If you spent as much time helping to get CML2 up and going as some of you
> have trying to kill it (while not offering anything constructive to replace
> it) it would have been DONE 6 months ago.

I consider CML2 an albatross now, and the maintainer does not listen to
feedback.

Contrary to what you think, I'm not trying to kill CML2.  In it's
present state, according to kernel developers other than me, it is NOT
ready for inclusion.  Now, by all appearances, Eric is trying to ram
CML2 down Linus's throat without resolving the problems kernel
developers have with it.

I would be happy as a clam if Eric wanted to resolve the problems -we-
have with CML1 and the config system, not just the problems he has with
it.

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Jeff Garzik <jgarzik@mandrakesoft.com>:
> I consider CML2 an albatross now, and the maintainer does not listen to
> feedback.

New FAQ entry:

* Eric doesn't listen to feedback.

Bill Stearns observed in February 2002 that "Eric has been very good
about folding in changes".  In response to feedback from the kernel
mailing list, Eric has:

- introduced the prefix declaration so that symbol names can be 
  expressed with or without the CONFIG_

- added a recovery mechanism so the configurator can do someting
  with inconsistent configs (this one was Alan Cox's issue).

- removed the magic tie declaration that made symbols without help
  only visible in EXPERT mode

- reorganized the rulebase to minimize stuff in the root rules file

- added the capability to annotate constraint violations with 
  text messages in English or the language of your choice.

- sped up the rulebase compiler by a factor of six

and many other changes comprising months of work.
 
> I would be happy as a clam if Eric wanted to resolve the problems -we-
> have with CML1 and the config system, not just the problems he has with
> it.

What problems do you have with CML1?  Name them and I will make sure
they are not issues in CML2.

I've been begging for feedback for many months.  Pleases *get specific*.
Instead of muttering that Eric refuses to listen, *give me something
to listen to*!
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

CML2 feedback (was Re: Disgusted with kbuild developers)

[Jeff Garzik]

"Eric S. Raymond" wrote:
> What problems do you have with CML1?  Name them and I will make sure
> they are not issues in CML2.
> 
> I've been begging for feedback for many months.  Pleases *get specific*.
> Instead of muttering that Eric refuses to listen, *give me something
> to listen to*!

(cc'ing Linus)

1) Remove global dependencies.
> source "arch/um/rules.cml"
> source "arch/i386/rules.cml"
> source "arch/alpha/rules.cml"
> source "arch/sparc/rules.cml"
[...]

All symbols should not be included on every config run.  The
architectures currently create their own master rules file, which then
selectively includes other config files.  You break this and remove
control (and flexibility) by enforcing something globally which was
previously done on a per-arch basis.


2) As discussed in December (as well as before and after that thread),
the --eventual-- direction to go is that a single file will contain all
meta information about a driver or set of drivers.  Config.help entries,
Config.in entries, Makefile rules, etc.  The idea is to group
information about a particular object in the same location.  So,
considering (a) that Config.help now exists and (b) this eventual
direction, splitting up rules and symbols into completely separate files
is not the greatest idea... when we eventually want to integrate rules
and symbols.


Take a look at what we find in Donald Becker's virgin source tree, in
winbond-840.c:
> /* Automatically extracted configuration info:
> probe-func: winbond840_probe
> config-in: tristate 'Winbond W89c840 Ethernet support' CONFIG_WINBOND_840
> 
> c-help-name: Winbond W89c840 PCI Ethernet support
> c-help-symbol: CONFIG_WINBOND_840
> c-help: The winbond-840.c driver is for the Winbond W89c840 chip.
> c-help: This chip is named TX9882 on the Compex RL100-ATX board.
> c-help: More specific information and updates are available from 
> c-help: http://www.scyld.com/network/drivers.html
> */

All the information is in one location.  Now, Linus said not to embed
this information in the source, but put it in a metadata file.  But
other than that, this is a small and simple example of what the metadata
config files might eventually look like.


So, my own personal opinion is that CML2 should follow these suggestions
:)

Regards,

	Jeff



-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Disgusted with kbuild developers

[Nicolas Pitre]

On Sat, 16 Feb 2002, Eric S. Raymond wrote:

> Jeff Garzik <jgarzik@mandrakesoft.com>:
> > I consider CML2 an albatross now, and the maintainer does not listen to
> > feedback.
> 
> New FAQ entry:
> 
> * Eric doesn't listen to feedback.
> 
> Bill Stearns observed in February 2002 that "Eric has been very good
> about folding in changes".  In response to feedback from the kernel
> mailing list, Eric has:
[...]

Eric has selectively listened to feedback he found interesting and still 
persist in resisting most others.

You ignored mine so far, even if they are like the ones made by many others.

Make the whole thing ___***IDENTICAL***___ to CML1.
Do a formal translation of CML1 into CML2.

Show us that you are clever enough to do so, even if it's not particularly 
interesting and challenging to you.

Show us that you can listen to this simple feedback.

Acknoledge that the feedback went through.

Don't tell us that's not doable.  Do it and show us that you can do a 
perfect translation of CML1 into CML2 with all CML1 structural flaws.

Submit that, and only that.

Do you copy?  Please acknoledge that you listened to this very feedback.


Nicolas

Re: Disgusted with kbuild developers

[Eric S. Raymond]

Nicolas Pitre <nico@cam.org>:
> Make the whole thing ___***IDENTICAL***___ to CML1.
> Do a formal translation of CML1 into CML2.
> 
> Show us that you are clever enough to do so, even if it's not particularly 
> interesting and challenging to you.
> 
> Show us that you can listen to this simple feedback.
> 
> Acknoledge that the feedback went through.
> 
> Don't tell us that's not doable.  Do it and show us that you can do a 
> perfect translation of CML1 into CML2 with all CML1 structural flaws.
> 
> Submit that, and only that.
> 
> Do you copy?  Please acknoledge that you listened to this very feedback.

I listened.

Would you ask someone designing a new VM to make it crash and hang exactly
the same way the old one did?

Do you demand that a rewrite of a disk driver have the same data-corruption
bugs as the original before it can go into the tree, and tell the developer
to add fixes later?

Pragmatically, the point of rewriting a system is to *fix bugs*.

Let's suppose we ignored this point for a moment.  Let's also suppose
that what you were demanding were not rendered horribly painful and
perhaps impossible by the difference between CML1's imperative style
and CML2's declarative one.

How the hell do you possibly think I could possibly stay motivated under
that constraint?  Nobody is paying me to do this.  I'm a volunteer; I
need to produce good art, not waste time slavishly recreating old errors
just because a few people are unreasonably fearful of change.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Re: Disgusted with kbuild developers

[Jeff Garzik]

"Eric S. Raymond" wrote:
> Let's suppose we ignored this point for a moment.  Let's also suppose
> that what you were demanding were not rendered horribly painful and
> perhaps impossible by the difference between CML1's imperative style
> and CML2's declarative one.
> 
> How the hell do you possibly think I could possibly stay motivated under
> that constraint?  Nobody is paying me to do this.  I'm a volunteer; I
> need to produce good art, not waste time slavishly recreating old errors
> just because a few people are unreasonably fearful of change.

If you are not prepared to evolve the system, you are not familiar with
kernel development...  Prove that CML2 is good and needed by breaking it
up into steps, reaching the final goal...  Good ole Al Viro's patch
progressions are an excellent example to emulate :)

	Jeff


-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"

Re: Disgusted with kbuild developers

[Nicolas Pitre]

On Sat, 16 Feb 2002, Eric S. Raymond wrote:

> Nicolas Pitre <nico@cam.org>:
> > Do you copy?  Please acknoledge that you listened to this very feedback.
> 
> I listened.

Good.  We therefore can make progress.
By your comments below we now know that you listened and that it's 
extremely painful for you to admit the truth.  But you must understand the 
nuances if you want to go somewhere with CML2.

> Would you ask someone designing a new VM to make it crash and hang exactly
> the same way the old one did?
> 
> Do you demand that a rewrite of a disk driver have the same data-corruption
> bugs as the original before it can go into the tree, and tell the developer
> to add fixes later?

Your examples are flawed.  The person who fix bugs in the VM doesn't use any 
other language than the original one.  The person who do a rewrite of a disk 
driver doesn't change anything in the struct rational purpose of reading and 
writing blocks of bytes on a media.

> Pragmatically, the point of rewriting a system is to *fix bugs*.

Indeed!  However CML2 is __way__ more than only bug fixing.  If you qualify 
your current CML2 inclusion proposal as only "bug fixes" it's much too much 
under estimating the work you did and the effort you put in it.

I'm sure people will agree with the fact that the CML2 syntax is much more 
enjoyable to read and work with.  The fact that all frontends are using the 
same parser eliminates bugs already.  That's the part most people have 
nothing against.  For god sake submit those parts and leave the rest for a 
later discussion!

Admit that in the tremendous work you did, there are parts that people will 
disagree with.  Don't spoil it all by not separating things and only 
presenting it as a big unknown blat!

For people to have confidence in CML2 it must be proposed in multiple 
incremental changes -- changes that are small enough (either conceptually or 
physically) for people to be able to grok them without too much effort.  You 
must also be prepared to see people wanting to modify things in some ways 
you didn't think about along the process.  That's why only producing a 
strict CML1 --> CML2 translation would already be a big enough step for now.

> Let's suppose we ignored this point for a moment.  Let's also suppose
> that what you were demanding were not rendered horribly painful and
> perhaps impossible by the difference between CML1's imperative style
> and CML2's declarative one.

Do what's necessary so the translation is a near as possible and the result 
in say 'make config' is the same (same questions as before).  You certainly 
can do that with some bits of awk.  If you can't come with something 
similar, you're then already admiting yourself that CML2 is so big a change 
that people are right to be afraid of it.

> How the hell do you possibly think I could possibly stay motivated under
> that constraint?  Nobody is paying me to do this.  I'm a volunteer; I
> need to produce good art, not waste time slavishly recreating old errors
> just because a few people are unreasonably fearful of change.

First, by doing what I described above, you'll please more people than you 
can imagine.  Next you must be prepared to face the possibility that your 
art might not be adopted integrally.  You should be motivated by the 
percentage that gets adopted in the end.

When Al Viro decides to rewrite the VFS, he doesn't submit it to Linus as a
single big opaque patch to replace the old code at once.  If he did, he
would probably still be waiting for Linus to merge his art.

Note the nuance:  we don't criticize your art but rather the way you present 
it.  It might be the best configuration tool ever, but untroduce it in 
incremental steps and leave some slack between them for those who didn't 
work on it for the last year to digest them.  Please be wise so not to waste 
your art.


Nicolas

Re: Disgusted with kbuild developers

[Matt D. Robinson]

[ everything deleted ]

Wow, I'm amazed at the amount of time spent on this thread,
when people could have actually been doing real work, or
maybe just enjoying family, friends, life ...

I hope it comes to some useful resolutions,

--Matt

Of Bundling, Dao and Cowardice

[Alexander Viro]

On Sat, 16 Feb 2002, Eric S. Raymond wrote:

> Would you ask someone designing a new VM to make it crash and hang exactly
> the same way the old one did?
> 
> Do you demand that a rewrite of a disk driver have the same data-corruption
> bugs as the original before it can go into the tree, and tell the developer
> to add fixes later?
> 
> Pragmatically, the point of rewriting a system is to *fix bugs*.

	That, folks, is a fine example of very common problem.
It's very tempting to try and force your ideas of How The Things
Should Be Done(tm) into the tree by bundling them with genuine
bug fixes and (more or less gracefully) refusing to split the
patch.  Anybody who had done serious work on the tree had felt
that temptation at one point or another.  No arguments - it's very
attractive.  Indeed, you don't have to defend every point of your
design and implementation - you can always point to Bad Bugs(tm)
that are fixed by the entire thing and obfuscate the objections away.
The trouble being, _SUCH_ _BUNDLING_ _IS_ _NOT_ _A_ _VALID_ _STRATEGY_.

	It had been tried.  Many times.  Sometimes it even got the
thing into the tree.  _All_ such cases had lead to trouble.

	There is another way.  It takes more efforts, it requires
readiness to defend every damn part of your design and it means
that you will have to deal with the sad fact that parts of that
design need to be redone.  It will take more time.  It will look
less sexy.  It may very well mean that somebody else will get
alternative design into the tree on the top of your efforts.
There are only two positive things about it - it is honest and
it leads to better tree.

	How does it work?  Simple - look at the path from original
tree to tree with your modifications.  And no, "one big jump" doesn't
count.  Think of the way your ideas can be split into parts.  Think
of the way obstructions to the changes can be split into parts.
Find small and simple changes that can go in right now, would improve
the tree and would make the rest of path easier.  And merge them.
If you find that it can't be done - think what needs to be changed in
the tree (or in your modifications) to make the split possible.
If you see that something is ugly and stands in the way - help the thing
to achieve the form it wants.  That may change all your ideas about the
right design for your modifications.  That's OK - it's a Good Thing(tm).
And merge the small changes.  Step by step.

	_That_ works.  Less glory; more time; more work.  And better
tree afterwards.  The code wants to get cleaner.  In many directions.
The trick is to pick the right ones and let the thing grow into natural
form.  Do that many times in the right order and you will get it where
you want it to be.  Quite possibly - in a better place than you thought
originally.

	Before you start saying that it's impossible - THAT HAD BEEN DONE.
Between 2.3.40 and 2.5.2 (about two years) we got pretty much complete
redesign of VFS,  along with the stuff that was plain impossible with
the old design.  Get the old tree.  Get the current tree.  Compare.  And
realize that more than half of the way was covered during 2.4.  Yes, the
total size of patches had been about 2 times larger than the size of
combined patch.  Definitely took a lot of extra efforts.  You know what?
It was worth the trouble.  Result is better than what I've expected.  And
a lot of things in the first iteration of design had turned out to be
useless - stuff that was there to work around the problems that got _fixed_
by cleanups at some point during these two years.  And I fully expect to
see the same thing happening with the stuff I'm planning and doing now.

	While we are at it, look what Rik is doing right now.  He has
a huge patch pretty much rewriting (what a coincidence) VM.  He had tried
to shove its previous incarnations into the tree whole-sale.  Saying that
it didn't work is putting it _very_ mildly - resulting fight is in l-k
archives and boy, was it nasty...  Look what's going on now - same splitup
and gradual merge strategy.  Sure, extra work.  Guess what?  The thing had
already become better from that work.

	As for your motivations...  If you are doing that for bragging
rights ("I've thought up a new design and now it's in the tree, exactly
as I envisioned it") - find something else to brag about.  Your strategy
is basically a sign of cowardice - you are fighting tooth and nail to avoid
gradual changes and the only way I can interpret it is that you are afraid
to let parts of your design stand on their own.  Not exactly a bragging
material, that...

That Linux Guy <thatlinuxguy@hotmail.com>,Re: Of Bundling, Dao and Cowardice

[Rik van Riel]

On Sat, 16 Feb 2002, Alexander Viro wrote:

> 	While we are at it, look what Rik is doing right now.  He has
> a huge patch pretty much rewriting (what a coincidence) VM.  He had tried
> to shove its previous incarnations into the tree whole-sale.

Actually, Linus took it unexpectedly while I was away to
Europe for conferences for 2 weeks. ;)

I don't quite agree on the "more trouble" part either,
in the end it is MUCH more trouble when a big blob of
code gets integrated than when a series of small changes
get applied one by one.

regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: That Linux Guy <thatlinuxguy@hotmail.com>,Re: Of Bundling, Dao and Cowardice

[bill davidsen]

In article <Pine.LNX.4.33L.0202161713420.1930-100000@imladris.surriel.com> you write:

>I don't quite agree on the "more trouble" part either,
>in the end it is MUCH more trouble when a big blob of
>code gets integrated than when a series of small changes
>get applied one by one.

I would say "more than one idea" here, if something need changes in a
lot of places, so be it, they often won't work except as a whole. You
don't cross vast chasms in a series of small safe steps.

Hanging multiple indenpendent things in a single blob is bad practice,
of course.

-- 
bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc
  Programming without software engineering is like sculpting with a chain
saw. The very talented can produce a work of art, the mediocre wind up with
a misshapen lump in a pile of rubble, and in neither case does the end
result have more than a passing resemblance to the original intent.

Re: Of Bundling, Dao and Cowardice

[Oliver Xymoron]

On Sat, 16 Feb 2002, Alexander Viro wrote:

> 	How does it work?  Simple - look at the path from original
> tree to tree with your modifications.  And no, "one big jump" doesn't
> count.  Think of the way your ideas can be split into parts.

At least the rule base change from imperative -> inferential seems to
necessarily entail a single very large atomic change, given the arch-wide
rules present in the rulebase. This is the heart of the thing, and
ignoring for a moment Alan's claim that it's unnecessary, it's not at all
obvious that there's an incremental approach here. Any hints?

Hanging off the translation are things like the interpreter for the new
language bringing it up to parity with the old interpreter, which is a
meaningless delta by itself, but without which the core change is useless.
The orthogonal changes are relatively minor.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: Disgusted with kbuild developers

[Joel Becker]

On Sat, Feb 16, 2002 at 11:08:57AM -0500, Eric S. Raymond wrote:
> Nicolas Pitre <nico@cam.org>:
> > Make the whole thing ___***IDENTICAL***___ to CML1.
> > Do a formal translation of CML1 into CML2.
> 
> Would you ask someone designing a new VM to make it crash and hang exactly
> the same way the old one did?

	Eric, that's a slippery-slope argument.  You are bright enough
to know that is not what they meant.
	I like to stay out of flamewars, so I'm going to be nice,
simple, and to the point.  I hack kernels.  I build a lot of them.  I
use only make config and make oldconfig.  Here is what I want from a
config system (be it CML1 or CML2):
	make config goes through and asks me all the questions it needs
to.  The order can be different.  The slight format of the prompts can
be different.  The backend can be wildly different.  I don't CARE.  What
I do care about is that it only asks me relevant questions.  No "How old
is your computer?"  Never a "Do you like the color blue?"  None of that.
if it wants to know my CPU, it asks "What is your cpu? [386 486
Pentium/K6 ...]"  If it wants to know if I want sound support it asks
"Configure sound support?"  That's it.  I use make config because it
asks me every question, and I'm sure I haven't missed any.  When it is
done, I even know the macros it has set in config.h so I can peruse them
in the source.
	make oldconfig has to work like make old config.  Again, trivial
differences in the output layout don't matter.  Totally different logic
dont matter.  All that matters is that configuration questions I have
answered already don't get asked, and questions that are new to this
kernel do.
	The configuration metadata should be as close to the actual item
as possible.  I think everyone has come to this agreement.  You know,
drivers/scsi/aic_7xxx/aic_7xxx.cml or the like.  Fine.  I'm not even
sure that I care all that much about this.  So if everyone can come to a
level of agreement on this, I'm sure I'll be fine.
	The last thing I require is that it doesn't affect my build
time.  The kernel takes a while to build right now, even on my
dual-GHz machines with >GB RAM.  I've not played with CML2 much, but the
rumours of it taking twice as long for a build are scary.  CML2 should
have completed all of its work when make *config exited.  All of the
logic after the completion of make *config and make dep should be in the
Makefiles, just like it does in CML1.  Now, if I've got that wrong, let
me know.  I sure hope you aren't executing CML2 programs during make
bzImage.
	Until CML2 can come to do this, I'm going to stay perfectly
happy with CML1.  mconfig just makes it easier.

Joel


-- 

"The first requisite of a good citizen in this republic of ours
 is that he shall be able and willing to pull his weight."
	- Theodore Roosevelt

			http://www.jlbec.org/
			jlbec@evilplan.org

Re: Disgusted with kbuild developers

[Rob Landley]

On Saturday 16 February 2002 11:06 am, Nicolas Pitre wrote:

> Don't tell us that's not doable.  Do it and show us that you can do a
> perfect translation of CML1 into CML2 with all CML1 structural flaws.

"Hey, the new VM in 2.4.10 should have replicated the swap overload failure 
case in 2.4.9!  The first implementation should definitely melt down exactly 
the same way!  We need to artificially introduce all the flaws in the old 
one, just to prove it can be done!  Otherwise the new code is not 
interesting."

"To get people to try Linux on the desktop, first we need to make it 
blue-screen just like windows."

"It's unfair to compare laptops to desktops unless you first remove the 
battery from the laptop."

What the...?

Wouldn't it be nice if there was an implementation of CML2 that did 
everything CML1 did -EXCEPT- for the structural flaws?  Rather than a blind 
mindless drooling bug-for-bug clone that defeats the whole purpose of 
reimplementing the thing?

Your requirement seems to be based on the blind assumption that CML1 had 
nothing whatsoever wrong with it, and CML2 didn't need to be done in the 
first place.  If that's your argument, then say it directly.  (That might be 
a defendable position.  The one you just stated isn't.)

As for breaking CML2 so it's capable of producing a configuration that the 
rulebase says won't compile, the way CML1 can...  You do understand the 
difference between a procedural and a declarative language, right?

Rob

Re: Disgusted with kbuild developers

[Nicolas Pitre]

On Sat, 16 Feb 2002, Rob Landley wrote:

> On Saturday 16 February 2002 11:06 am, Nicolas Pitre wrote:
> 
> > Don't tell us that's not doable.  Do it and show us that you can do a
> > perfect translation of CML1 into CML2 with all CML1 structural flaws.
> 
> "Hey, the new VM in 2.4.10 should have replicated the swap overload failure 
> case in 2.4.9!  The first implementation should definitely melt down exactly 
> the same way!  We need to artificially introduce all the flaws in the old 
> one, just to prove it can be done!  Otherwise the new code is not 
> interesting."

Rob:

Please read my other mails, understand the nuances, then come back, OK?


Nicolas

Re: Disgusted with kbuild developers

[Matthias Andree]

On Sat, 16 Feb 2002, Nicolas Pitre wrote:

> Make the whole thing ___***IDENTICAL***___ to CML1.
> Do a formal translation of CML1 into CML2.

This requirement is contrary to CML2's objective. CML2 is not about
re-implementing CML1 tools and bugs in another language, there are at
least two current projects for that, one of them is mconfig.

-- 
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin

Re: Disgusted with kbuild developers

[Martin Dalecki]

That Linux Guy wrote:

>The amount of whining I've had to read today on this topic just astonishes
>me.  People, please - devote 1/10th of the energy to helping esr finish and
>fix CML2 to meet Linus' expectations.  Face the fact:  CML1 was good for
>it's time, but that time is now gone.
>
The fact is CML1 works fine enough for me. In fact fine engough means - 
I never have
any problems with it. *THIS* is what makes the inclination to replace it 
with something else
so low. And this is a good thing. No change for the sake of it is a 
primal principle in good
software design.

Re: Disgusted with kbuild developers

[Rob Landley]

On Friday 15 February 2002 01:55 pm, Eric S. Raymond wrote:
> Alexander Viro <viro@math.psu.edu>:
> > > Neither Linus nor anyone else ever said to me "Eric, it's your job to
> > > make that change."  When I asked for guidance, Linus blackholed my
> > > mail.
> >
> > Oh!  Come and see the violence inherent in the system!
> > Help!  Help!  I'm being repressed!
>
> Your reply was pretty funny.  Well, I laughed anyway.
>
> But laughter won't make the chronic communications problems go away.

Speaking as a proud member of Al Viro's killfile (from one work account and 
one home accounts, each time for lkml postings he wasn't cc:'d on, which 
somehow set him off anyway), I really doubt he perceives lack of 
communication as much of a problem.  More of a solution. :)

Seeing a conspiracy in the existence of any posts to public mailing lists 
other than linux-kernel is, however, the kind of paranoia for which 
medication is prescribed.  (Would the reactionary front have preferred Eric 
email the various developers directly in a big CC:, instead of a posting to a 
PUBLIC LIST, which apparently Jeff DID find and highlighted?  I'd say the 
"help help this is being repressed" came at the start of this thread, not 
when Eric jumped in.)

And when did talking to Linus directly (in email or on the phone) become 
something that Linus needed to be protected from?  (Look out guys!  Some 
people are thinking of TALKING DIRECTLY TO LINUS!  Without consulting us 
first!  They must be found and stopped!)

And here I thought Linus was very good at saying no, in a multitude of 
contexts...

Rob

Re: Disgusted with kbuild developers

[Martin Dalecki]

Eric S. Raymond wrote:

>Alexander Viro <viro@math.psu.edu>:
>
>>>Neither Linus nor anyone else ever said to me "Eric, it's your job to 
>>>make that change."  When I asked for guidance, Linus blackholed my mail.
>>>
>>Oh!  Come and see the violence inherent in the system!
>>Help!  Help!  I'm being repressed!
>>
>
>Your reply was pretty funny.  Well, I laughed anyway.
>

You didn't reach for your usual potence substitute called a weapon?
Didn't you?

Re: Disgusted with kbuild developers

[Rik van Riel]

On Fri, 15 Feb 2002, Jeff Garzik wrote:

> ESR's message to the kbuild list:
> 	http://marc.theaimsgroup.com/?l=kbuild-devel&m=101373619625183&w=2
> The rest of the thread:
> 	http://marc.theaimsgroup.com/?t=101373623000001&r=1&w=2
>
> For an open source "guru", Eric, you sure seem to like to turn to
> cronyism and secret meetings when the going gets tough.

This makes me wonder whether Eric works in a cathedral
or in an ivory tower ...

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: Disgusted with kbuild developers

[Alexander Viro]

On Fri, 15 Feb 2002, Rik van Riel wrote:

> On Fri, 15 Feb 2002, Jeff Garzik wrote:
> 
> > ESR's message to the kbuild list:
> > 	http://marc.theaimsgroup.com/?l=kbuild-devel&m=101373619625183&w=2
> > The rest of the thread:
> > 	http://marc.theaimsgroup.com/?t=101373623000001&r=1&w=2
> >
> > For an open source "guru", Eric, you sure seem to like to turn to
> > cronyism and secret meetings when the going gets tough.
> 
> This makes me wonder whether Eric works in a cathedral
> or in an ivory tower ...

Judging by usual Eric's intellectual erm... output the word you are looking
for is "outhouse".

Re: Disgusted with kbuild developers

[Michael Alan Dorman]

Jeff Garzik <jgarzik@mandrakesoft.com> writes:
> For an open source "guru", Eric, you sure seem to like to turn to
> cronyism and secret meetings when the going gets tough.

Yeah, you should have heard him four years or so ago suggesting that
due to the ncurses license he would be able to deny Thomas Dickey
ownership of his own code when Thomas (who had been doing all
significant development on ncurses for a year or more) attempted to
make his own release of ncurses (4.1, as I recall).

Fortunately all parties agreed to the code being assigned to the FSF,
getting ESR out owning a critical-path library.

Mike.