Oh sure. :)
I pondered adding various comments along the lines of "Don't insult the
intelligence of the people you're sending it to by assuming they can't break
it out for themselves. Do assume they're lazy enough to tell YOU to do it,
and reject the whole patch until then. Ask yourself: would you rather get
some of your code into the kernel, or none at all?"
And also a longer admonition, that getting mad about this sort of thing is a
very common problem among newbies, and you just have to grow up and learn to
leave all-or-nothing behind and live with shades of grey to function around
here in the long term.
But I was trying very hard to keep it short. Feel free to amend the patch if
you can think of anything better to say. :)
I was also trying not to wander off topic. There are all sorts of related
areas like "gradual transition" vs "flag day" approaches to large patches.
For now, if they're doing a large enough patch we can assume they've been
enculturated. (Well, mostly.) In the long term, "theory of linux-kernel
development" might not belong belong in SubmittingPatches. Maybe a seperate
document, or in a FAQ somewhere, or the README... Dunno.
> (And I do like that you broke the log rolling change out; very good
> object lesson. :) )
>
> Eli
Thanks. It seemed the thing to do. :)
Rob
-
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/