All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: John Bradford <john@grabjohn.com>
Cc: diegocg@teleline.es,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	ml@basmevissen.nl
Subject: Re: time for some drivers to be removed?
Date: Thu, 24 Jul 2003 14:31:05 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0307241422360.21139@localhost.localdomain> (raw)
In-Reply-To: <200307241829.h6OITjR3000582@81-2-122-30.bradfords.org.uk>

On Thu, 24 Jul 2003, John Bradford wrote:

> i wrote:

> > and in the end, while i know some folks don't think it's a big
> > deal, i think doing a "make allyesconfig" really should work.
> 
> It's _counter productive_ just to bodge it so that make allyesconfig
> works.  I _want_ it to _fail_ if the drivers are _broken_.
> 
> A CONFIG_KNOWN_BROKEN option is a good thing, in the case where,
> E.G. a SCSI driver is broken, and will randomly corrupt data, but
> otherwise compiles and appears to work.  Apart from that, it's a
> complete waste of time to fiddle around with silly options that do
> nothing but bloat the codebase and waste developers' time.

whoa, calm down.  i didn't mean to start that kind of flame war. for the
record, i feel that, if something is *known* to be broken, it should not
be in the source tree.  naturally, in the testing process, there will
be stuff that has bugs, which is why we test.  but i'm just not buying
the argument of leaving modules like riscom8 in the tree for release
after release when it hasn't compiled properly for as long as i can
remember.

but the impression i've gotten so far is that some folks are adamant that
some broken/non-updated/legacy/obsolete/whatever code will remain in the
source tree because it might be fixed *some day*.  if that's the case,
then i think such code should be marked or tagged *somehow* as being
broken.

it's a matter of public perception -- it looks bad to ship code that
is *known* not to compile.

and on that note, i'll let this one go.  my $0.02.  $0.03 canadian.

rday

p.s.  and, yes, i think "make allyesconfig" should just plain work
for official release kernels.  so there. :-P

  reply	other threads:[~2003-07-24 18:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-24 18:29 time for some drivers to be removed? John Bradford
2003-07-24 18:31 ` Robert P. J. Day [this message]
2003-07-24 19:31   ` Eli Carter
2003-07-25 10:48 ` Bas Mevissen
  -- strict thread matches above, loose matches on Subject: below --
2003-08-14  5:34 John Bradford
2003-08-13 20:55 John Bradford
2003-08-13 20:50 ` Adrian Bunk
2003-08-13 20:55 ` Bill Davidsen
2003-08-05 12:42 Mikael Pettersson
2003-08-05 13:03 ` Adrian Bunk
2003-08-05 13:35   ` Mikael Pettersson
2003-08-05 13:48     ` Adrian Bunk
2003-08-05 14:01       ` Mikael Pettersson
2003-08-06 10:06         ` Claus-Justus Heine
2003-08-09 19:40           ` Adrian Bunk
2003-08-05 16:35 ` Alan Cox
2003-08-05 18:47   ` Leopold Gouverneur
2003-07-28  7:12 linux
2003-07-27 16:22 John Bradford
2003-07-25 11:10 John Bradford
2003-07-24 14:43 John Bradford
2003-07-24 19:24 ` Brian Jackson
2003-07-24 12:20 Robert P. J. Day
2003-07-24 14:58 ` Alan Cox
2003-07-24 15:34   ` Bas Mevissen
2003-07-24 17:32     ` Diego Calleja García
2003-07-24 17:50       ` Robert P. J. Day
2003-07-24 19:16         ` Diego Calleja García
2003-07-24 19:43           ` Robert P. J. Day
2003-07-24 18:02       ` Samuel Flory
2003-07-24 19:07     ` Alan Cox
2003-07-25 10:48       ` Bas Mevissen
2003-07-27 15:31 ` Adrian Bunk
2003-07-27 15:59   ` David D. Hagood
2003-07-27 16:18     ` Adrian Bunk
2003-07-27 16:40     ` Alan Cox
2003-07-27 17:00       ` Adrian Bunk
2003-07-27 18:45       ` David D. Hagood
2003-07-27 20:40         ` Alan Cox
2003-07-27 20:56           ` Adrian Bunk
2003-07-27 20:56             ` Alan Cox
2003-07-28  2:23               ` Herbert Pötzl
2003-07-29 19:33               ` Adrian Bunk
2003-08-13 20:16                 ` Bill Davidsen
2003-08-09 18:04   ` David Woodhouse
2003-08-09 19:36     ` Adrian Bunk

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=Pine.LNX.4.53.0307241422360.21139@localhost.localdomain \
    --to=rpjday@mindspring.com \
    --cc=diegocg@teleline.es \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ml@basmevissen.nl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.