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