"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
oh, and while i'm here, i'm going to point out a couple other things you should avoid if you're trying to get your first patch into the kernel -- unsurprisingly, nick has violated both of these guidelines a number of times.
first, good grammar. seriously, good grammar. if you can't use proper grammar for the single-line "Subject" field, you really have no business submitting patches.
and second, your explanation for the patch (what goes into the commit log) should *match* the patch. in particular, do not claim that you are fixing an "error" when all you're doing is cleaning up a *warning*. nick is a major violator of this prime directive -- do not categorize something as an "error" if it isn't. end of story.
I do understand who you are addressing here, but I fear this is a little like a school teacher asking the children to be quiet - Those who listen are never the ones you want to shut up... So, with that in mind, I'd like to disagree about *first* patch requirements. The only way you can truly screw up your first kernel patch, is by not submitting it. It's of course always an advantage to have read and followed any advice you have found. And with everything indexed by a search engine, you are expected to have found some. But not everything. Do not worry, you will be politely pointed to the rest if necessary. For subsequent submissions you are of course required to read all comments and fixup the issues that are pointed out, so you might as well fix as much as possible before the first submission. But you shouldn't worry about posting a patch with some unresolved issues you weren't aware of, if it's your first kernel patch submission ever. Bjørn