public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miles Lane <miles@megapathdsl.net>
To: Benedict Bridgwater <bennyb@ntplx.net>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Brown-paper-bag bug in m68k, sparc, and sparc64 config files
Date: 19 May 2001 18:51:30 -0700	[thread overview]
Message-ID: <990323493.13903.0.camel@agate> (raw)
In-Reply-To: <3B0718AB.7E2FF3A2@ntplx.net>
In-Reply-To: <3B0718AB.7E2FF3A2@ntplx.net>

On 19 May 2001 21:06:51 -0400, Benedict Bridgwater wrote:
> > This bug unconditionally disables a configuration question -- and it's
> > so old that it has propagated across three port files, without either
> > of the people who did the cut and paste for the latter two noticing it.
> >
> > This sort of thing would never ship in CML2, because the compiler
> > would throw an undefined-symbol warning on BLK_DEV_ST.  The temptation
> > to engage in sarcastic commentary at the expense of people who still
> > think CML2 is an unnecessary pain in the butt is great.  But I will
> > restrain myself.  This time.
> 
> So a shortcoming of the CML1 tools justifies the CML2 language?
> 
> I guess the next bug found in the Python2 interpreter will justify
> writing CML3 in FORTRAN.

IIRC, Eric floated the CML2 idea over a year ago, provided some
rudimentary code and requested feedback.  There has seemed, for a long
time, to be agreement amoungst most kernel developers that there were
serious problems with CML1 and that it needed to be junked. There are
many things that CML1 was not going to allow us to do that will be
possible with CML2 (subsetting of the code tree, etc). I don't think
Eric's statement about this particular brown-paper-bag bug means that he
thinks that this alone justifies migrating to CML2. There are a lot of
good reasons for the migration. It isn't, perhaps, a perfect solution,
but it is one that Eric has implemented with a year's worth of effort,
with full knowledge of the kernel development community and with an open
invitation for contributions and feedback. To rag on it now seems
belated and unhelpful. It would be more useful if you helped Eric
improve CML2, since there appears to be agreement that it will be used
in 2.5.

	Miles


  reply	other threads:[~2001-05-20  1:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-20  1:06 Brown-paper-bag bug in m68k, sparc, and sparc64 config files Benedict Bridgwater
2001-05-20  1:51 ` Miles Lane [this message]
2001-05-20  2:14   ` Ben Bridgwater
2001-05-20  3:14     ` Keith Owens
2001-05-20  1:51 ` Miles Lane
  -- strict thread matches above, loose matches on Subject: below --
2001-05-19 22:10 Eric S. Raymond
2001-05-20  4:10 ` Mike Galbraith

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=990323493.13903.0.camel@agate \
    --to=miles@megapathdsl.net \
    --cc=bennyb@ntplx.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