lkml.org 
[lkml]   [1998]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.1.83: Sound, SB16, Modules, MIDI?
On Thu, 5 Feb 1998, Alan Cox wrote:
> > There contributions are generaly going to make it into the offical tree,
> > sooner or later. There are also maintainers of vairous peices
>
> Oh don't believe that. Linus can be quite explicit about code he doesnt like
> and won't be going into his tree whoever wrote it ;)
OK, granted. But it is certianly much easyer for a recognised uberhacker to
get code in the kernel: I often see one of you guys post a "looks good"
patch, and have it appear in the next kernel, faster then tested patches
from other people get in.

> > (mostly drivers). They can do pretty much whatever they want to those
> > peices, and Linus will take patch-sets from them. But Linus can change any
> > code he wants, though if you are modifing a mantained driver, it is
> > considered more civilized to go through them.
>
> People do occasionally do things like send me a driver saying "Can you put
> this in the kernel for me", I just bounce those to the proper place anyway
> unless its directly related to stuff Im working on/with.
Even with your MAC port, the 3C501 driver, and sound? That isn't realy the
role of a "maintainer", is it? (From MAINTAINERS: "Someone actually looks
after it.") In any case, I still think this applies.

> I do often pick up
> build and test bits from the kernel list as a sort of ongoing hoover mode,
> mostly little fixes that seem to have gotten overlooked.
Indeed, because it is easyer for you, as an uber-hacker, to get code in,
because you are widly known as producing little crap, and lots of Good Stuff.

> > The normal way seems to be:
> > 1) Write the New Way in, breaking all the drivers.
> > 2) Change one driver as an example.
> > 3) Write a sepperate patch that steps on everyone's toes, or declare
> > everything obsolete <G>.
>
> Not until after 2.2 please. Also external API's are generally sacred even
> if you shred the internals occasionally.
Don't you mean not in a stable kernel? I think the code freeze is officaly
dead, considering the IRQ API change recently.

> Alan
-=- James Mastros
--
"I'd feel worse if it was the first time. I'd feel better if it was
the last."
-=- "(from some Niven book, doubtless not original there)"
(qtd. by Chris Smith)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans