[Mesa-dev] [v3 PATCH 01/10] mesa:Define extension ARB_framebuffer_no_attachments

[Connor Abbott]

On Thu, May 21, 2015 at 8:51 PM, Rogovin, Kevin <kevin.rogovin at intel.com> wrote:
>
>> FWIW, the kernel standards for commit messages are at:
>> https://www.kernel.org/doc/Documentation/SubmittingPatches
>> Most of those rules apply to Mesa too. It says the body should be wrapped to 75 chars (although I've been using 72 like Matt said).
>
> This is my point: "use most rules, but not all".. and "I've been more conservative than X but I did not need to be". What I am seeing is that there is, in some collective form, a set of consistent rules (in the form of ranges) that are strongly enforced and yet not written down.
>
> Let's write them all  down here and now, put them in some file for others to read and to refer to. Maybe even con someone to write a lint-like script for those rules.
>
> -Kevin

I said "use most rules, but all" because I'm expecting you to use your
common sense to see what rules apply and which might need to be
modified to apply to Mesa. For example, as you've probably noticed,
Mesa doesn't have any formal maintainers like Linux does, so the
process for getting your patch into the tree goes from "get a sign-off
from the maintainer and they'll merge it into their tree" to "get a
reviewed-by from someone well-known and familiar with the code you're
modifying, and they'll commit it if you don't have commit access."
Usually figuring out who that is pretty straightforward (hint: git
blame), but if not you can ask.

We don't have a style guide or the equivalent of checkpatch.pl for the
same reason we don't have formal maintainers: the project isn't large
enough, and doesn't have enough infrastructure, for it. There haven't
been enough people like you that have to be hand-fed every detail to
justify the work; instead, we just note problems when they occur and
rely on the patch author to fix them. If there's anyone to be "conned"
to do that work, it's going to be you. You've certainly been given
enough information by now to be able to do so.

Finally, I'll quote a section of the file I linked to:

"Be sure to tell the reviewers what changes you are making and to
thank them for their time.  Code review is a tiring and time-consuming
process, and reviewers sometimes get grumpy.  Even in that case,
though, respond politely and address the problems they have pointed
out."

Everyone makes mistakes. Heck, I just sent out a series with some
minor style nits that Matt pointed out. When that happens, you fix the
problem, try to remember it for the future, and then move on. Starting
a 13 (now 14) email thread where you do nothing but complain about it
is a great way to not get your patches merged, and that would be a
good thing to remember in case you actually care about getting them
merged; but if you don't, then why did you send them and waste our
time in the first place?

Connor