On Thu, May 21, 2015 at 8:51 PM, Rogovin, Kevin <kevin.rogo...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev