Patch Set 2:
just because you felt like it without taking any of the objections that you knew were there into account
I did take them into account. At some point everything boils down to a small set of fundamentally incompatible objections to different options. It's called a compromise.
or even trying to discuss the issue again first.
"Discuss as much as you please as long as in the end you do what I want"?
Code style is always subjective, but that means that it should only be changed by consensus or at least by clear majority opinion.
Let's just say that 80 cols aren't really being followed in our tree:
$ git grep -E "^.{82}" src/ |wc -l
219683
Therefore I reject the idea that there's consensus that our coding style _is_ 80 cols.
You don't have that here, you're just doing whatever you want
Note that I didn't merge this change (and I would have let it linger for a while longer, specifically to sort out the remaining questions). I'm no stranger to having commits hang around for 2 years or longer.
and completely ignoring the fact that there are hundreds of other developers on this project who may or may not agree with your subjective change. *That* is what I'm opposed against!
Have fun opposing your imaginary straw man with your imaginary developer army, but please leave me out of that.
If you want to align clang-format to the coding style we use in coreboot,
Which coding style would that be, in practice?
the status quo on that clearly is 80,
Clearly not. See above.
so you can upload a patch that sets "ColumnLimit: 80" and I'll happily +2 that.
I thought the rough consensus was "80 columns except where it _really_, _really_ makes sense"? In that case ColumnLimit: 80 (which sets a hard boundary) is of no use.
you can't just change it willy-nilly without making some effort to confirm that most of the community is in favor of your change first.
I think this discussion is going on and off for longer than you contribute to coreboot, and it was only recently that most people who participated grudgingly agreed to something (for some, 96 is still _way_ too limiting). "willy-nilly"? Please.
As far as I am aware we consider clang-format an option for developers who chose to use it, and there are no plans to change that.
The mere existence of util/lint/lint-*022* disagrees with "just an option" (and note, the only I change I did in that space was to move it from experimental to stable, but util/lint is the wrong place for optional non-rules.)
I would likely be opposed to it if there were (and I assume others would be as well, e.g. it sounds like Nico is not a fan either).
As Ron reports from other projects, nobody is happy with it before, while everybody seems to accept it afterwards.
(I am not sure what setting ColumnLimit: 0 *and* removing the checkpatch check is supposed to accomplish... if you're trying to say we should remove the line length limit altogether, then no, I'm obviously not in favor of that either.)
ColumnLimit: 0 doesn't mean that clang-format makes every line as long as possible, but that it leaves lines alone that it doesn't touch and otherwise creates lines as long as necessary. A concession to that "80 columns except where it makes sense" thing.
Since apparently the strongest opinions on that (not necessarily a "majority" by any metric) are for artisanal source code, I guess the only resort we have is to drop both checkpatch and clang-format and continue to rely on the services of Paul and Elyes to keep us in line with a style guide that nobody really follows anyway. I'll prepare a patch.
To view, visit change 31651. To unsubscribe, or for help writing mail filters, visit settings.