archive mirror
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <>
To: Tomas Szepe <>
Cc: Linux kernel mailing list <>
Subject: Re: some kernel config menu suggested tweaks
Date: Sat, 26 Jul 2003 08:30:59 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0307260821570.30928@localhost.localdomain> (raw)
In-Reply-To: <>

On Sat, 26 Jul 2003, Tomas Szepe wrote:

> > []
> > 
> > 1) i mentioned this before, i think, but after one deselects
> >    Power management, should ACPI Support and CPU Frequency
> >    scaling still be available?
> > 
> >    the "make xconfig" menu display suggests a submenu 
> >    structure there, which clearly isn't the case.
> Why don't you go ahead and send a patch?
> > 2) can all of the low-level SCSI drivers be made deselectable
> >    in one swell foop?  folks might want SCSI support just for
> >    generic support and SCSI (ide-scsi) emulation, but have no
> >    interest in low level SCSI drivers.
> Add a SCSI lowlevel drivers submenu (~4 lines of Kconfig).
> > 3) can all of ATM support be deselected with a single click?
> >    in the same way "PCMCIA network device support" is done just
> >    above it under "Networking options"?
> Send a patch.

i'd be happy to, but based on my previous experience sending
in a few patches, it's just not worth the aggravation any more.

just one of my patches that got adopted took, literally, several
weeks of being dropped on the floor with no reason why.  and i
had to resubmit it, slightly updated, for every BK rev of the
kernel since the previous patch wouldn't apply cleanly --
it might be a line or two off, which would require remaking
the patch and resubmitting it *again*.  at which point, it
would be dropped on the floor *again*.

don't get me wrong -- i understand that there has to be some
form of QA in accepting kernel patches, and after a while, 
regular submitters can build up a reputation.

but, at this point, it's not terribly useful to encourage people
to submit patches if those patches are just tossed.

it's like the classic catch-22:

  "we can't hire you.  you don't have enough experience doing
    this job."
  "ok, so how do i get experience?"
  "well, you have to do this job for a while."

uh, right.  so, while there's not much point in my submitting
patches, i can still toss suggestions from the sidelines, unless
you have some ideas.  i'm certainly open to advice.


  reply	other threads:[~2003-07-26 12:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-24 17:05 some kernel config menu suggested tweaks Robert P. J. Day
2003-07-26 12:14 ` Tomas Szepe
2003-07-26 12:30   ` Robert P. J. Day [this message]
2003-07-26 13:01     ` Tomas Szepe
2003-07-26 13:45     ` Randy.Dunlap
2003-07-24 18:45 John Bradford
2003-07-24 18:49 ` Robert P. J. Day
2003-07-24 19:10 John Bradford
2003-07-24 19:53 ` Petr Vandrovec
2003-07-26 12:52 ` Tomas Szepe
2003-07-26 13:07   ` Robert P. J. Day
2003-07-26 14:33     ` Tomas Szepe
2003-07-26 15:20 John Bradford

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:

* 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.0307260821570.30928@localhost.localdomain \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).