a couple other common patch submission boo boos

[Bjørn Mork]

"Robert P. J. Day" <rpjday at 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