From: "Eric S. Raymond" <esr@thyrsus.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Horst von Brand <brand@jupiter.cs.uni-dortmund.de>,
linux-kernel@vger.kernel.org, kbuild-devel@lists.sourceforge.net
Subject: Re: CML2-2.1.3 is available
Date: Thu, 17 Jan 2002 09:29:17 -0500 [thread overview]
Message-ID: <20020117092917.A7905@thyrsus.com> (raw)
In-Reply-To: <20020116204345.A22055@thyrsus.com> <20020116164758.F12306@thyrsus.com> <esr@thyrsus.com> <200201162156.g0GLukCj017833@tigger.cs.uni-dortmund.de> <20020116164758.F12306@thyrsus.com> <26592.1011230762@redhat.com> <20020116204345.A22055@thyrsus.com> <3515.1011257639@redhat.com> <20020117083757.A7299@thyrsus.com> <13681.1011276592@redhat.com>
In-Reply-To: <13681.1011276592@redhat.com>; from dwmw2@infradead.org on Thu, Jan 17, 2002 at 02:09:52PM +0000
David Woodhouse <dwmw2@infradead.org>:
> Utter crap. CML2 makes them possible, and is a step in the right direction.
> I'm not suggesting that you never make these changes - just that you do them
> separately from the change in mechanism.
Sorry, it's *way* too late for that. In fact, it was already way too
late for that at the kernel summit last March when Linus issued his ukase.
The "change in mechanism" phase of the project was essentially complete
almost a year ago now. If you had been paying attention, you would
have noticed this.
The idea that a pure change in mechanism could ever have been cleanly
separated from changes in behavior was a fantasy anyway. Large changes in
a software architecture just don't work that way, as we rediscover every
time a significant subsystem gets reworked to fix bugs.
I have held off on many things that I think badly need to be done in
order to pacify the conservative instincts of people like yourself --
for example, I think the device menus cry out to be reorganized on a
functional basis rather than on the basis of internal distinctions
like "block" vs. "character" devices that are pointless to anyone
but a kernel implementor.
But if attempting that implausibility of no behavioral changes is what
you think I "agreed" to, we'd best both forget the "agreement" --
because it would be hypocrisy if I agreed falsely and an absurd,
project-strangling shackle if I agreed sincerely.
Continuity, avoiding gratuitous changes, and a good-faith effort to
emulate the interfaces people are expecting is one thing; artificial
stasis is entirely another. I'm doing my best to give you the former.
You won't get the latter, no way, nohow.
If you have spotted errors, the time to tell me about them is *now*.
It's unfair to me and to other developers to artificially hold off
until we pass some mythical point at which it will suddenly be OK for
behavior to change. The real world doesn't work that way, and I am
sure you are too experienced to believe it does.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
If a thousand men were not to pay their tax-bills this year, that would
... [be] the definition of a peaceable revolution, if any such is possible.
-- Henry David Thoreau
next prev parent reply other threads:[~2002-01-17 14:46 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-15 19:53 CML2-2.1.3 is available Eric S. Raymond
2002-01-15 20:15 ` Nicolas Pitre
2002-01-15 20:18 ` Eric S. Raymond
2002-01-15 20:41 ` Nicolas Pitre
2002-01-15 19:19 ` Rob Landley
2002-01-16 3:48 ` Eric S. Raymond
2002-01-16 6:29 ` Peter Samuelson
2002-01-16 6:32 ` Eric S. Raymond
2002-01-16 7:13 ` Peter Samuelson
2002-01-16 6:36 ` Alexander Viro
2002-01-16 0:15 ` Henning P. Schmiedehausen
2002-01-15 20:16 ` Anton Altaparmakov
2002-01-15 20:24 ` Eric S. Raymond
2002-01-15 19:30 ` Rob Landley
2002-01-16 3:58 ` Eric S. Raymond
2002-01-15 20:25 ` Russell King
2002-01-15 19:37 ` Rob Landley
2002-01-17 1:18 ` Val Henson
2002-01-21 16:22 ` Daniel Phillips
2002-01-21 17:05 ` [kbuild-devel] " Giacomo Catenazzi
2002-01-21 23:11 ` Daniel Phillips
2002-01-22 6:29 ` Kai Henningsen
2002-01-23 21:45 ` Daniel Phillips
2002-01-16 0:38 ` Peter Samuelson
2002-01-15 20:26 ` Ross Vandegrift
2002-01-16 4:02 ` Eric S. Raymond
2002-01-16 16:38 ` Ross Vandegrift
2002-01-16 16:59 ` Ross Vandegrift
2002-01-16 18:29 ` Rob Landley
2002-01-18 18:32 ` Ross Vandegrift
2002-01-22 5:31 ` Eric S. Raymond
2002-01-15 20:27 ` Robert Love
2002-01-15 21:09 ` David Lang
2002-01-16 15:06 ` Horst von Brand
2002-01-16 21:31 ` Eric S. Raymond
2002-01-16 21:56 ` Horst von Brand
2002-01-16 21:47 ` Eric S. Raymond
2002-01-17 1:26 ` David Woodhouse
2002-01-17 1:43 ` Eric S. Raymond
2002-01-17 8:53 ` David Woodhouse
2002-01-17 13:37 ` Eric S. Raymond
2002-01-17 14:09 ` David Woodhouse
2002-01-17 14:29 ` Eric S. Raymond [this message]
2002-01-16 23:36 ` David Lang
2002-01-18 6:48 ` Kai Henningsen
-- strict thread matches above, loose matches on Subject: below --
2002-01-22 9:11 [kbuild-devel] " Giacomo Catenazzi
2002-01-22 9:20 ` Keith Owens
[not found] <fa.d4sn1fv.b78io8@ifi.uio.no>
[not found] ` <fa.i3p6mlv.1mg2frl@ifi.uio.no>
2002-01-22 10:09 ` Giacomo Catenazzi
2002-01-22 10:25 ` Keith Owens
2002-01-22 10:48 ` Giacomo Catenazzi
2002-01-22 10:53 ` Keith Owens
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=20020117092917.A7905@thyrsus.com \
--to=esr@thyrsus.com \
--cc=brand@jupiter.cs.uni-dortmund.de \
--cc=dwmw2@infradead.org \
--cc=kbuild-devel@lists.sourceforge.net \
--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