archive mirror
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <>
To: "Robert P. J. Day" <>
Subject: Re: some kernel config menu suggested tweaks
Date: Sat, 26 Jul 2003 06:45:01 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <Pine.LNX.4.53.0307260821570.30928@localhost.localdomain>

On Sat, 26 Jul 2003 08:30:59 -0400 (EDT) "Robert P. J. Day" <> wrote:

| 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?

Ditto.  the right response.

| 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.

and the QA is on patches, not (so much) on dialog.

| 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.

But suggestions from the sidelines are just too close to whinging
(Brit. spelling :) and moaning.  Not very helpful.


  parent reply	other threads:[~2003-07-26 13:32 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
2003-07-26 13:01     ` Tomas Szepe
2003-07-26 13:45     ` Randy.Dunlap [this message]
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 \ \ \ \ \ \

* 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).