Re: Disgusted with kbuild developers

Re: Disgusted with kbuild developers

[Michael Elizabeth Chastain]

I'm the creator and one of the current administrators of the kbuild-devel
mailing list.  kbuild-devel is not an instrument of "cronyism" or
"secret meetings".

I think it's reasonable and scalable for kernel subsystems to have their
own mailing lists.  And I think it's reasonable to expect people who
have an interest in a subsystem to look in MAINTAINERS for any mailing
lists and web sites for that subsystem.  As of 2.5.4, the MAINTAINERS
file lists 91 such mailing lists, including:

  CONFIGURE, MENUCONFIG, XCONFIG
  L: kbuild-devel@lists.sourceforge.net
  W: http://kbuild.sourceforge.net

Yeah, some cabal I started here, cleverly hidden in MAINTAINERS.

When Eric Raymond started the CML2 project, he came to the CML1 maintainer
(me) and asked me what I thought.  I referred him to the public list and
we had a public discussion about the project.  The root of the discussion
is here:

  http://www.torque.net/kbuild/archive/0181.html

So while people are chastising Eric for bundling controversial
improvements with CML2, or pushing for a 2.4 backport, or writing in
python, or writing in python2, I think it's unfair to suggest that he
developed CML2 in secret.  He didn't.  He read the MAINTAINERS file
and then held numerous discussions in the appropriate public forum.
You may reject the fruits of his project, but I'm here to say that he
developed it in an open fashion.

(I have to say, reluctantly, that I'm personally not happy with the tactic
of asking kbuild-devel people to send mail to Dirk Hohndel.  I don't have
any acquaintance with Dirk, but I'm sure that he's capable of writing
to kbuild-devel himself if he wants to solicit opinions from there.
I say "reluctantly" because as an administrator of the list, I don't want
to get into criticism of list postings.)

As far as CML1 goes: I got discouraged in April 2000, when Linus
blackholed documentation patches from me for several months in a row.
So I took a hiatus for two years.  Two things have changed since then:
Linus agreed to be more responsive, and other people (specifically Dave
Jones) are offering kernel trees.  So I'm going to give it another shot.
I'm responding to every CML1 patch and bug report which is submitted to
kbuild-devel, and I'm sending patches to Linus and Dave.

I believe that CML1 is rococo and I welcome a replacement.  I think that
leapfrog development is a good strategy here, just as it was for ALSA.
I'll look after the current system, and other people can focus their
attention on the next generation.

Here are my reasons for wanting to get rid of CML1:

. A Microsoft engineer wrote scripts/Configure.  For three years, I have
  lived in fear that Microsoft would notice this fact and use it to attack
  Linux through public relations channels or legal means.  They haven't yet,
  so I have been wrong so far.

. A language must have a written definition, so that people writing
  scripts in the language have a good chance that their scripts will keep
  working as other people enhance the configuration tools.  CML1 has
  a retro-fitted language definition with lots of gaps in it.  

. An implementation must have a real parser that gives real syntax errors.
  Menuconfig in particular likes to get all weird if there are syntax
  errors in the input.  xconfig used to crash a lot in those cases;
  but it has gotten better.

. The language itself does not scale up to the thousands of symbols that
  we have today.  There's a fundamental tension between "hide all the
  symbols for busses that I don't have" and "I want this feature,
  so auto-enable everything I need to get it".

As far as which way to replace CML1 goes: I'm not worried about the
technical specifications of the language, so long as it has one.  I would
like to remove every trace of Microsoft intellectual property from the
kernel, which is an argument in favor of a new language as well
as a new implementation.  I would like the new system to come with plenty
of documentation.  And I would like the new system to have a maintainer
who really believes in it.  CML2 has these properties so I support it.

Other projects, such as Christoph Hellwig's current version of mconfig,
also have these properties (except for keeping the same language) and
are also viable replacements for configure/Menuconfig/xconfig.

Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"

Re: Disgusted with kbuild developers

[Jeff Garzik]

Michael Elizabeth Chastain wrote:
> I'm the creator and one of the current administrators of the kbuild-devel
> mailing list.  kbuild-devel is not an instrument of "cronyism" or
> "secret meetings".
[reshuffle the message a bit]
> (I have to say, reluctantly, that I'm personally not happy with the tactic
> of asking kbuild-devel people to send mail to Dirk Hohndel.  I don't have
> any acquaintance with Dirk, but I'm sure that he's capable of writing
> to kbuild-devel himself if he wants to solicit opinions from there.
> I say "reluctantly" because as an administrator of the list, I don't want
> to get into criticism of list postings.)

I never meant to suggest that about kbuild-devel -- having the
appearance of being an attempt to [IMO] push a bad change via Dirk when
pushing it other ways [IMO] failed was really offensive to me...


> I think it's reasonable and scalable for kernel subsystems to have their
> own mailing lists.

No argument

> So while people are chastising Eric for bundling controversial
> improvements with CML2, or pushing for a 2.4 backport, or writing in
> python, or writing in python2, I think it's unfair to suggest that he
> developed CML2 in secret.  He didn't.

No one's suggesting that.  It's more the appearance of "I couldn't do it
the normal way, let me try this other, non-open route..."


> I believe that CML1 is rococo and I welcome a replacement.  I think that
> leapfrog development is a good strategy here, just as it was for ALSA.

I think this is a key mistake.  See Al's message "Of Bundling, Dao,
...".

It's impossible to prove that Eric's CML2 rulebase reflects a current
CML1 rulebase, primarily for this reason.  My review of arch/alpha/* and
drivers/net/* configs between CML1 and CML2 showed divergent rules and
dependencies which simply don't exist in CML1 and often should not in
CML2.

Surely we can prove through -evolution- that CML2 is or is not the best
direction for the future.  All or nothing is this case is impossible to
prove correctness.


> Here are my reasons for wanting to get rid of CML1:

no arguments


> As far as which way to replace CML1 goes: I'm not worried about the
> technical specifications of the language, so long as it has one.  I would
> like to remove every trace of Microsoft intellectual property from the
> kernel, which is an argument in favor of a new language as well
> as a new implementation.  I would like the new system to come with plenty
> of documentation.  And I would like the new system to have a maintainer
> who really believes in it.  CML2 has these properties so I support it.

Those are meta-properties.  The origin of code, be it MicroSoft or not,
should not be a factor.  In fact, -allowing- it to be a factor is
allowing MicroSoft some additional weight in technical decisions, which
should not occur IMO.

CML2 has global dependencies that the current system does not.

CML2 has a rulebase which is different from the current rulebase, with
no documentation or adequate explanation for these changes, and with no
good way to prove these changes are correct and reflect the current
rulebase for [pick your tree].

CML2's syntax is not reflective of the direction of being able to plop
down "driver.c" and "driver.conf" and having the config/make system
magically notice it.  It goes in the opposite direction, increasing the
number of places in $cml-rules-file that one must patch when adding a
driver [especially one with strange arch-specific dependencies, such as
an S/390-specific net driver].


> Other projects, such as Christoph Hellwig's current version of mconfig,
> also have these properties (except for keeping the same language) and
> are also viable replacements for configure/Menuconfig/xconfig.

Would you support the replacement of in-kernel
configure/Menuconfig/xconfig with in-kernel mconfig?

I mentioned this to Christoph, and he violently disagreed that it should
go into the kernel, and I violently disgreed with him :)  The kernel
absolutely MUST have some in-kernel configuration currently.  And
mconfig is clearly a better tool.

If we want to migrate to a point where all kernel configuration is
maintained solely outside the kernel, I actually support that.  But as a
SEPARATE migration step.  I do not want to drop all config tools from
the kernel and tell people "use mconfig" in the same breath.

	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

[Pavel Machek]

Hi!

> . A Microsoft engineer wrote scripts/Configure.  For three years, I have
>   lived in fear that Microsoft would notice this fact and use it to attack
>   Linux through public relations channels or legal means.  They haven't yet,
>   so I have been wrong so far.

What's problem with Microsoft people helping with configure? Not *all* of them
are evil. And GPL is designed to prevent legal abuse from them.
I can't imagine PR attack. "Oh, look, we helped to develop Linux and it
is not killing us"?
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: Disgusted with kbuild developers

[Daniel Phillips]

> . A Microsoft engineer wrote scripts/Configure.  For three years, I have
>   lived in fear that Microsoft would notice this fact and use it to attack
>   Linux through public relations channels or legal means.  They haven't yet,
>   so I have been wrong so far.

Teehee.  I don't think you have anything to worry about, Microsoft would be
incredibly embarassed to admit they're contributing to 'problem number 1'.

-- 
Daniel

Re: Disgusted with kbuild developers

[Felix von Leitner]

Thus spake Michael Elizabeth Chastain (mec@shout.net):
> . A Microsoft engineer wrote scripts/Configure.  For three years, I have
>   lived in fear that Microsoft would notice this fact and use it to attack
>   Linux through public relations channels or legal means.  They haven't yet,
>   so I have been wrong so far.

That is not something Microsoft could leverage.
Actually, it is something Linux can leverage against Microsoft, because
Microsoft keeps on telling people that using GPL is a nightmare because
it forces all your intellectual property on the street for free.  They
proved that wrong themselves.  That is quite a strong argument.  It
should be publicized, not buried.  We should thank them publicly.

Felix

RE: Disgusted with kbuild developers

[Keith Moore]

> That is not something Microsoft could leverage.
> Actually, it is something Linux can leverage against Microsoft, because
> Microsoft keeps on telling people that using GPL is a nightmare because
> it forces all your intellectual property on the street for free.  They
> proved that wrong themselves.  That is quite a strong argument.  It
> should be publicized, not buried.  We should thank them publicly.
>
> Felix

Don't read too much into this. As I understand it, the "Microsoft Engineer"
that wrote scripts/configure did this work on his own time, not as part of a
Microsoft project team.


Keith

Re: Disgusted with kbuild developers

[Giacomo Catenazzi]

Greg Banks wrote:

> G'day,
> 
> Michal Jaegermann <michal@harddata.com> 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 believe I'm the anonymous `he' you refer to.

There are two other projects of C implementation of CML2:

cml2config in sourceforce, and another I lost the link.


	giacomo

Re: Disgusted with kbuild developers

[Greg Banks]

Giacomo Catenazzi wrote:
> 
> There are two other projects of C implementation of CML2:
> 
> cml2config in sourceforce,

  I've spoken with these guys.  They're using Prolog and a new
language which they're inventing.  Their goal of a smarter inference
engine is interesting from a theoretical point of view, but if you
don't like Python you're going to *loathe* their stuff.

> and another I lost the link.

  Well, good luck to them, whoever they are.

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

Re: Disgusted with kbuild developers

[Greg Banks]

G'day,

Michal Jaegermann <michal@harddata.com> 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 believe I'm the anonymous `he' you refer to.

>  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".

  I had the impression that most people just stopped whingeing on lkml
but didn't actually try the code.  I've had very very little feedback
or apparent interest on gcml2.  In the meantime ESR's Python code got
less buggy and faster and I upgraded my main devel box to a distro
which had Python2 on it.  The Python code had limped up to the `adequate'
mark and my time is finite so I moved on.

  Look if I thought gcml2 was a serious contender to be used as the kernel
config tool of choice I would drop everything else and finish it.

>  Now it turns out the the project got abandoned [...] Hm..., smells
> very backdoor even if it was not intended that way. 

  So you're implying that I colluded with ESR to use gcml2 as a decoy
to ease acceptance of his Python2 implementation?  Hah, I *wish* I was
that organised or devious!

Greg.
-- 
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down.	   - Roger Sandall, The Age, 28Sep2001.

Re: Disgusted with kbuild developers

[Giacomo Catenazzi]

Daniel Phillips wrote:

>>. A Microsoft engineer wrote scripts/Configure.  For three years, I have
>>  lived in fear that Microsoft would notice this fact and use it to attack
>>  Linux through public relations channels or legal means.  They haven't yet,
>>  so I have been wrong so far.
>>
> 
> Teehee.  I don't think you have anything to worry about, Microsoft would be
> incredibly embarassed to admit they're contributing to 'problem number 1'.


I agree, but we know some strange 'behaviour' of MS.
They have a lot of lawers, they can make us a lot of trouble.
(You will notice that there are no copyright statment on that file,
only the name of authors).

Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
way to include 'free' patches: sign and send to FSF a piece of paper,
that the patches CAN be included.
I think nobody in Linux have done that, thus we can expect some
more troubles and microsoft is a large troubles-maker

	giacomo

Re: Disgusted with kbuild developers

[Alexander Viro]

On Tue, 19 Feb 2002, Giacomo Catenazzi wrote:

> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
> 
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.
> I think nobody in Linux have done that, thus we can expect some
> more troubles and microsoft is a large troubles-maker

... and script in question is fscking trivial to reimplement if and when it
happens.  End of story.

Re: Disgusted with kbuild developers

[Daniel Phillips]

On February 19, 2002 09:04 am, Giacomo Catenazzi wrote:
> Daniel Phillips wrote:
> >>. A Microsoft engineer wrote scripts/Configure.  For three years, I have
> >>  lived in fear that Microsoft would notice this fact and use it to attack
> >>  Linux through public relations channels or legal means.  They haven't 
> >>  yet, so I have been wrong so far.
> > 
> > Teehee.  I don't think you have anything to worry about, Microsoft would 
> > be incredibly embarassed to admit they're contributing to 'problem number 
> > 1'.
> 
> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
> 
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.

Under the GPL Having exclusive copyright just means that you can relicense 
later stuff if you want.  I'm not clear on why FSF considers it so important
but for Linux it just means that nobody, not even Linus, can ever release
under a new license (e.g., the BSD license).  So actually, having multiple 
copyright holders is a good thing for you, it protects your investment in GPL 
capital better.  I say, if Microsoft employees want to contribute to Linux, 
the more the merrier.  Heck, even billg is going to wake up on day (with a 
start, in the middle of the night) and realize which way the wind is blowing. 
Steve Jobs did.

> I think nobody in Linux have done that,

Great.

> thus we can expect some more troubles and microsoft is a large 
> troubles-maker

Oh yes...

-- 
Daniel

Re: Disgusted with kbuild developers

[Bill Davidsen]

On Tue, 19 Feb 2002, Daniel Phillips wrote:

> On February 19, 2002 09:04 am, Giacomo Catenazzi wrote:

> Under the GPL Having exclusive copyright just means that you can relicense 
> later stuff if you want.  I'm not clear on why FSF considers it so important
> but for Linux it just means that nobody, not even Linus, can ever release
> under a new license (e.g., the BSD license).  So actually, having multiple 
> copyright holders is a good thing for you, it protects your investment in GPL 
> capital better.  I say, if Microsoft employees want to contribute to Linux, 
> the more the merrier.  Heck, even billg is going to wake up on day (with a 
> start, in the middle of the night) and realize which way the wind is blowing. 
> Steve Jobs did.

So did IBM, SCO, HP and Sun. We shall see what transpires...

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Disgusted with kbuild developers

[Pavel Machek]

Hi!

> >>. A Microsoft engineer wrote scripts/Configure.  For three years, I have
> >> lived in fear that Microsoft would notice this fact and use it to attack
> >> Linux through public relations channels or legal means.  They haven't 
> >> yet,
> >> so I have been wrong so far.
> >>
> >
> >Teehee.  I don't think you have anything to worry about, Microsoft would be
> >incredibly embarassed to admit they're contributing to 'problem number 1'.
> 
> 
> I agree, but we know some strange 'behaviour' of MS.
> They have a lot of lawers, they can make us a lot of trouble.
> (You will notice that there are no copyright statment on that file,
> only the name of authors).
> 
> Remember the RMS (a flame with the word 'ESR' MUST have also the 'RMS' :-))
> way to include 'free' patches: sign and send to FSF a piece of paper,
> that the patches CAN be included.
> I think nobody in Linux have done that, thus we can expect some
> more troubles and microsoft is a large troubles-maker

FSF is actually doing something completely different, they want to be
able to change copyrights.
									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

[Giacomo Catenazzi]

Matthias Andree wrote:

> 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.


But making the translation in 3 steps make think easier:
- Change the engine (CML2), the rules are rewritten, but
   functionally nearly identical to old rules
   (Big patch)
- Change the rules (with a lot of small patches)
- Change the interface (not really need)

	giacomo

Re: Disgusted with kbuild developers

[SodaPop]

I can't believe you people, even if you are high level kernel
maintainers.
   
The most major complaints I see against CML2 are that 'the
behaviour is different from CML1' and 'CML2 has a whole bunch of
"features" too which will be shoved down our throats'.
          
Duh!  That was the freaking point!  Granted I'm not a kernel hacking
expert, but I've been building my own kernels since 1995 and I see
definite value in having the side effects and grouping stuff in
CML2.  I also see significant value in having the symbol set and
rules provably coherent.
                       
You guys change the low level kernel interfaces all the time.  You
change module interfaces out from underneath people every other
month.  You depreciate malloc.h and replace it with slab.h and
don't so much as give it a second thought, yet you bitch up a
storm about how the changes in CML2 behaviour are unacceptable?
                                                              
You guys force changes down the throats of other people all the
time.  Well now, in my lowly opinion, it's time for you to do what
everyone else is already used to - choke it down, and comfort
yourself by saying 'it was the right thing to do.'
                                                 
Looking forward to seeing CML2 in 2.5,

-dennis T

Re: Disgusted with kbuild developers

[Daniel Phillips]

On February 18, 2002 04:15 pm, SodaPop wrote:
> I can't believe you people, even if you are high level kernel
> maintainers.
>    
> The most major complaints I see against CML2 are that 'the
> behaviour is different from CML1' and 'CML2 has a whole bunch of
> "features" too which will be shoved down our throats'.
>           
> Duh!  That was the freaking point!  Granted I'm not a kernel hacking
> expert, but I've been building my own kernels since 1995 and I see
> definite value in having the side effects and grouping stuff in
> CML2.  I also see significant value in having the symbol set and
> rules provably coherent.
>                        
> You guys change the low level kernel interfaces all the time.  You
> change module interfaces out from underneath people every other
> month.  You depreciate malloc.h and replace it with slab.h and
> don't so much as give it a second thought, yet you bitch up a
> storm about how the changes in CML2 behaviour are unacceptable?

Right.  The bitching and moaning is stupid.  Lets move on.
                                                         
> You guys force changes down the throats of other people all the
> time.  Well now, in my lowly opinion, it's time for you to do what
> everyone else is already used to - choke it down, and comfort
> yourself by saying 'it was the right thing to do.'
>                                                  
> Looking forward to seeing CML2 in 2.5,

Yup.

-- 
Daniel

Re: Disgusted with kbuild developers

[Michael Elizabeth Chastain]

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

Eric S. Raymond <esr@thyrsus.com>:
> 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.

I disagree with this statement in three different ways.

[1] lkml readers are kbuild users, not kbuild developers

kbuild is special.  The relationship between most lkml readers and most
linux kernel code (such as the VM) is the relationship of developers to
a corpus of code.  The relationship of most lkml readers to kbuild is
the relationship of *users* to a corpus of code.  I think of everybody
that has not submitted patches or written code to kbuild tools as a
kbuild user.

Oddly enough, people behave differently in their roles as users than
their roles as developers.  Many people who have actually worked on
menuconfig would love to shitcan that monstrosity, but people who run
menuconfig don't mind the ugliness of its implementation.

The first thing users want to know about a software upgrade is: "is it
going to break what I am doing right now".  In a mature system, it really
is better to leave 10 old bugs unfixed rather than introduce one new bug.
I believe that is why people ask for functional equivalence, even for bugs.
Users do not trust developers to decide which behaviours are bugs!

In order to do my work, it has to match some internal concepts I have
about correctness, elegance, robustness, all that stuff.  But in order
for other people to want to use my work, it has to match their concepts
of what is useful to them.

[2] CML1 is working in the field

Your view is that CML1 is as bad as a VM that crashes or locks up.
This view is rejected by a significant number of CML1 users, including a
lot of influential ones.  People are building kernels with CML1 every day.

Even if you believe that CML1 as a language has hopeless problems, you
should acknowledge that many users do not believe this.  So when you
show up and say "here, CML2 language will solve all your CML1 language
problems", you are offering a lot of people something negative or neutral
to them.

A month ago I was disenheartened about this.  It looked like CML1
language was going to be "good enough" for the entire lifespan of the
Linux kernel.  Now it turns out that there is a new customer requirement:
people want driver.conf files.  A new language has the opportunity to
define driver.conf files and that would be a significant advantage
over CML1.

[3] kernel development is highly multi-threaded with interesting locks

The kernel development process involves hundreds of people across several
trees.  It's fundamentally different from one person writing code on
one branch of one tree -- the same way that a massive multi-threaded
program running on a 256-processor server is programmed differently than
a single-threaded program on a uniprocessor.

I believe there are development locks.  I could probably write a
whole essay on the nature of these locks, the atomic operations in the
development process, the way that people use multi-phase protocols to
get something merged without grabbing giant locks, and so on.

Kbuild work has the unfortunate property that it sometimes needs big
locks.  I think that CML2 involves a giant lock: you want to lock every
Config.in file at once, modify it from top to bottom, and commit them
all at once.  Okay.  That's a huge lock, especially considering that
at any given moment, lots of people have unmerged work-in-progress,
as well as whole parallel trees.

Linus can acquire a lock that big, because sometimes he just grabs the
Big Kernel Development Lock, changes some interface, and relies on us
mortals to patch up the loose edges.  This works pretty well because
it leverages his vision by letting other people share the grunt work.
But I think that Linus prefers to avoid grabbing the BKDL, and it's no
use pushing him.

I think it would be good for you to think about the nature of this locking
process (starting with: is mec onto something here or is he delusional?)
Then think about how to get to the end vision of CML2 with a less
severe locking strategy.

Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"

Re: Disgusted with kbuild developers

[Giacomo A. Catenazzi]

Jeff Garzik wrote:

> "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?


Why mconfig is not in the kernel? who maintain mconfig?
Why the first maintainer of mconfig prefer CML2?

> 
> 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.


now CML2 oldconfig behave like actual code. I would say too much.


	giacomo

re: Disgusted with kbuild developers

[Dan Kegel]

Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> 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.

>From my distant and peonic vantage point,
I don't see what the big deal is; Eric's messages
look perfectly fine.  Perhaps he should have cc'd linux-kernel,
but you could also argue that kbuild-devel was
exactly the right place to post discussions of
the kernel build system.  Eric is at worst guilty of
a minor misstep.  Don't pillory him; he really is simply
trying to do a good job.

Besides, it's not smart to insult a man who carries a gun :-)
- Dan

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"

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>

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

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.