<div dir="ltr">Hi,<br><div><br></div><div>In recent times, Mesa CI has grown the clang-format job which enforces formatting in some parts of the tree.</div><div><br></div><div>I hate this job, and I think the majority of Mesa developers also hate this job. This majority is, of course, excluding a small number of very vocal enthusiasts, as seen in e.g., <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23719">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23719</a> (a response to an admittedly unilateral action).</div><div><br></div><div>Why do I hate this formatting job, you might be asking. Let's look at a test pipeline from a recent refactoring series: <a href="https://gitlab.freedesktop.org/zmike/mesa/-/pipelines/1108274">https://gitlab.freedesktop.org/zmike/mesa/-/pipelines/1108274</a>.</div><div><br></div><div>Oh no, clang-format failed.<br></div><div><a href="https://gitlab.freedesktop.org/zmike/mesa/-/jobs/55270157">https://gitlab.freedesktop.org/zmike/mesa/-/jobs/55270157</a><br></div><div><br></div><div>Out of 4 hunks it rejected, all the fails are nonsensical line wrapping preferences that nobody cares about. In some cases, my changes didn't even affect the rejected lines, and yet somehow I am now responsible for "fixing" them. It's not the first time I've seen this sort of thing, and, even if line wrapping heuristics improve, I'm sure it won't be the last time this situation occurs.</div><div><br></div><div>These types of CI fails are a waste of both CI time and collective developer effort. If people want to enforce code formatting across their little part of the tree, that should be the responsibility of the reviewer.</div><div><br></div><div>To that end, I've created <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27702">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27702</a> which changes errors in clang-format jobs to warnings. If the job fails, the pipeline can still succeed. I think this is a better balance between people who want to opt-in to formatting checks for their parts of the tree and people who absolutely don't: if a reviewer cares about formatting, they're free to run a test pipeline and check the format job's results. If they aren't happy with it, they can block the MR until changes are addressed. This also provides some leeway where obviously stupid changes proposed by the job (as above) can be ignored.</div><div><br></div><div><br></div><div>Thoughts?</div><div>Mike</div></div>