[lkml]   [1998]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

     \ /
      Last update: 2005-03-22 13:41    [W:0.022 / U:4.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site