> It might be more productive to provide patches or at least generate
> constructive ideas as how to fix these problems, as you are obviously quite
> capable of doing so. Digging through the code and sending a new email to this
> list for every few flaws you find is doing little good, and your personal
> attacks on the maintainer are even less benefical. Cooperation will get you a
> lot farther than conflict.
Been there, tried that, had been told by Richard that he would rather fix
devfs bugs himself. Quite a few months ago. If you have better suggestions
they would be more than welcome.
As far as I can see, if maintainer doesn't fix the bugs himself and tells
that patches are not welcome there are only two things that can be done -
going into full-disclosure mode in hope that it will change the situation or
taking over the code in question.
By that point I'm sorely tempted to do the latter (i.e. full-blown fork,
maintained with no regard to Richard's preferences + sumbitting [very
massive] fixes directly to Linus), but I want to give a try to less
drastic approach first.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/