I'll accept patches still, but I want them explained better than they have
been so far. So far I have one huge patch that I can look at and say "ok,
this won't impact me", and as such it's in theory safe to apply. However,
at the same time I _know_ it will impact me in the future by me just being
in line to get the complaints.
What happened was that a _long_ time ago I decided to finally cut over to
the new FB-console stuff, because the m68k people swore up and down that
it was stable and good, and it had obviously been getting a lot of testing
on other non-x86 architectures. So I thought it was a no-brainer.
Instead of being a no-brainer, it turned out to be quite fundamentally
buggy, and I'm very grateful to Martin that he has been fixing the bugs.
But at the same time I'm _really_ disappointed by how the thing has been
handled, and very very disappointed by vger.
The reason I'm disappointed is that vger in particular has been acting as
a "buffer" between me and bug-fixes, so that now we're in the situation
that there are obviously bugs, and there are obviously bug-fixes, but I
don't see it as such, I only see this humongous patch.
I don't know what it fixes, because vger has kept me out of the loop, and
quite frankly I don't have the time to look at several hundred kilobytes
of compressed patches by hand. And I refuse to apply patches that I don't
feel comfortable with.
As a result, I want people to _tell_ me what the patch fixes. And that
probably means by now that I need to get each driver update on its own,
with explanations.
This is _exactly_ the same thing that made me hate vger when it came to
networking patches. And I'm going to ask David once again to just shut
vger down, because these problems keep on happening.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/