Ingo Molnar:
>If a patch gets ignored 33 times in a row then perhaps the person doing
>the patch should first think really hard about the following 4 issues:
>
> - cleanliness
> - concept
> - timing
> - testing
>
>a violation of any of these items can cause patch to be dropped *without
>notice*. Face it, it's not Linus' task to teach people how to code or how
>to write correct patches. Sure, he still does teach people most of the
>time, but you cannot *expect* him to be able to do it 100% of the time.
Since the "33 times in a row" seems to refer to my bad experience with the
Configure.help patches, I think I need to correct a misconception.
The patches in question were *documentation*. No concept issue, no
timing issue, no testing issue (I don't know what a "cleanliness"
issue would be in this context). I know that Michael Elizabeth
Chastain, the listed CML1 maintainer, has had similar frustrating
exoeriences trying to get documentation patches folded in.
We're not talking about obscure internals changes that could break the
kernel, we're talking zero-risk patches submitted by official maintainers.
This is not a situation that ought to require a lot of judgment or
attention on Linus's part.
The fact that Linus *does* have to pass on all such patches, and is
dropping a lot of them them on the floor, is the clearest possible
example of the weaknesses in the present system.
-- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> - 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/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:05 EST