How not to piss off a kernel subsystem maintainer - part 5
Heck, It's not like I haven't said all of this before, but it sure seems like
no one learns from the past, or reads the documentation that we write
for how to actually submit a patch for the kernel. Linux has one of the best
documented procedures for how to do this, it's not like it's a secret
Anyway, here's a list of patches that people have sent me in this week
alone that have caused me major problems:
- patch was never even build tested, and of course, it breaks when you do build it.
- patch does build, but it was never tested because the patch does the
opposite of what the submitter wanted to do.
- patch sent with no authorship
- patch sent with no signed-off-by line
- patch sent with no description of what the patch did
- patch sent with a description, yet it was not the description of the patch itself
- patch sent with a description that the patch only did one thing, yet
the patch did 4 different things
- patch sent with a description that made no sense at all
- patch sent in a series of 13 patches, all with the same exact subject,
and no description of what the patch did
- a one line patch that if applied, would instantly break the build
- patch that asked for reviews, yet gets angry when you ask why
something was done a certain way
- patch that asked for reviews, and when asked, can't explain why code
was done a certain way, blaming a non-existent person for that portion
- patch that said it fixed a bug, yet added a new feature without fixing
the original bug
- patch for cleaning up coding style issues, yet adds different coding issues
- patches asked for review, yet had obviously never been even run
through our automatic "test this patch for sanity" tools.
Yeah, it's been a fun week...
And if anyone ever wonders why code reviewers are grumpy, just look at
the above list and understand.