public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wayne.Brown@altec.com
To: esr@thyrsus.com
Cc: David Woodhouse <dwmw2@infradead.org>,
	Arjan van de Ven <arjanv@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Background to the argument about CML2 design philosophy
Date: Mon, 21 May 2001 12:36:48 -0500	[thread overview]
Message-ID: <86256A53.0060ACF6.00@smtpnotes.altec.com> (raw)



On 05/21/2001 at 05:04:40 AM esr@thyrsus.com wrote:

>See, I've already written off the chronic bellyachers.  Since I can't
>please them without scrapping the whole plan, I'm going to ignore
>them.  In particular, anybody who repeated "fsck Python..." after Linus
>ruled that Python is not an issue and Greg Banks announced the C
>implementation of CML2 has got a sufficiently severe case of
>rectocranial insertion that they've defined themselves out of the
>conversation.

I probably qualify as one of the bellyachers.  If so, I apologize.  It was not
my intention to disparage the work of Eric or anyone else involved in this
project.

Speaking from the perspective of a user of the CML tools, rather than as a
developer, all I've been trying to say is this:  When I type "make menuconfig"
or "make oldconfig" in the future, I want to see the same interface and the same
results that I've always seen, because it's always worked for me in the past.
It really doesn't matter to me if, down underneath, this is being done by CML1,
CML2, or a little man in my computer who slaughters chickens and reads their
entrails for omens to determine dependencies.  Right now I can grab a new -pre
or -ac patch, use oldconfig, and have a compile going in a few minutes, without
knowing or caring about the details of the config process.  In the rare case
that a patch breaks an existing driver, it takes only a couple of minutes with
menuconfig to disable that driver and compile without it, and then put it back
in when it's fixed.  And when, every once in a great while, I decide to scrap my
.config and start over, I can fly through all the menuconfig options very
quickly and make my customary selections almost without thinking about it.

I just want to be able to keep using the tools in this way.  If that's not going
to be possible... well, I'll adapt.  But from my point of view, learning a new
set of tools just to keep doing the same things I've always done isn't a
pleasant prospect.  I understand that changes may be necessary to meet others'
needs, but I'd like to see those changes made without affecting the way my own
needs are met.

I'm off my soapbox now and won't bellyache about it any further.

Wayne



             reply	other threads:[~2001-05-21 17:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-21 17:36 Wayne.Brown [this message]
2001-05-21 17:58 ` Background to the argument about CML2 design philosophy Eric S. Raymond
2001-05-21 20:00   ` Urban Widmark
2001-05-22  2:42     ` Eric S. Raymond
2001-05-22 14:42     ` john slee
2001-05-22 17:28       ` Daniel Phillips
  -- strict thread matches above, loose matches on Subject: below --
2001-05-21 19:05 Wayne.Brown
2001-05-21  3:01 Ben Bridgwater
2001-05-18 14:53 CML2 design philosophy heads-up Eric S. Raymond
2001-05-18 15:11 ` Arjan van de Ven
2001-05-18 15:26   ` Eric S. Raymond
2001-05-18 15:37     ` Arjan van de Ven
2001-05-18 15:49       ` Eric S. Raymond
2001-05-20 11:19         ` David Woodhouse
2001-05-20 15:18           ` Eric S. Raymond
2001-05-20 15:34             ` David Woodhouse
2001-05-20 15:44               ` Eric S. Raymond
2001-05-20 15:56                 ` David Woodhouse
2001-05-20 17:14                   ` Background to the argument about CML2 design philosophy Eric S. Raymond
2001-05-21  0:45                     ` Jes Sorensen
2001-05-21  9:14                     ` Helge Hafting
2001-05-21 11:32                     ` Jonathan Morton
2001-05-22 20:38                       ` Eric S. Raymond
2001-05-21 12:15                     ` David Woodhouse
2001-05-21 12:31                       ` Alan Cox
2001-05-21 23:11                       ` Jonathan Morton
2001-05-20 17:47                   ` David Woodhouse
2001-05-20 20:47                     ` Eric S. Raymond
2001-05-20 20:59                       ` Arjan van de Ven
2001-05-20 21:10                       ` Robert M. Love
2001-05-21  3:38                         ` Nicolas Pitre
2001-05-20 22:51                       ` David Woodhouse
2001-05-21  1:13                         ` Eric S. Raymond
2001-05-21  6:41                         ` David Woodhouse
2001-05-21 10:04                           ` Eric S. Raymond
2001-05-21 11:05                           ` David Woodhouse
2001-05-21 20:38                         ` John Stoffel
2001-05-22  0:59                           ` Keith Owens
2001-05-22  9:24                             ` Daniel Phillips
2001-05-23  1:51                               ` Keith Owens
2001-05-21 23:00                         ` Jonathan Morton
2001-05-22 13:45                         ` David Woodhouse
2001-05-22 16:21                           ` John Stoffel
2001-05-22 17:17                           ` David Woodhouse
2001-05-21  3:33                       ` Nicolas Pitre
2001-05-20 20:59                     ` David Woodhouse
2001-05-20 18:31                   ` Jonathan Morton
2001-05-20 20:13                     ` Eric S. Raymond

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86256A53.0060ACF6.00@smtpnotes.altec.com \
    --to=wayne.brown@altec.com \
    --cc=arjanv@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=esr@thyrsus.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox