I would prefer not to revert. No matter the reasoning
and latest discussions, this brings the configuration
closer to our coding style (that was copied from the
Linux kernel years ago). It says you may exceed the
80 chars limit if it increases readability.
Come on, that's not what that means and you know it. If you try to submit a patch to the Linux kernel where a line goes to 96 characters without good justification they'll reject you, as they always have. If you want to change the linter warning to "please strongly reconsider whether this line needs to be that long" or something like that, fine... but this change is currently being used as justification to rewrite lines in existing files that have absolutely no business being longer than 80 chars (e.g. https://review.coreboot.org/c/coreboot/+/31816/5/src/security/tpm/tspi.h), and that was clearly not the original intention of that coding style. You can't just reinterpret something that we have always interpreted for years as a pretty hard limit outside of really special cases and say "oh, 'increases readability' is clearly always given until you reach 96 chars".
Indeed, some people feel very strongly that 96 (or less, the horror!) is way too restrictive. That's what compromises are for: nobody is entirely happy, but everybody can somehow live with them.
This was already discussed at length previously (e.g. in CB:27533). The arguments for 80 characters are not primarily for the number itself but for consistency with other projects. Moving it to 96 characters isn't some compromise that makes everyone somewhat happy, it's just as bad for consistency as any other limit that's not 80.
I don't think it's appropriate to just sneak in such a wide-ranging and clearly very controversial policy change in the night without letting anyone know, especially when you previously tried and failed to convince the community at large of it. If I found someone else who's willing to +2 a revert of this and snuck that in without you noticing, would you be okay with that? Do we have to escalate this into a force submit war until we eventually try to remove each others' commit access or something like that? We have a community with many active members, we have a mailing list to discuss things and find a consensus, and when that doesn't work there are other ways to at least make a majority decision (e.g. that vote that was discussed but never implemented last time), but this is clearly not one of them. Whenever I try to make a change that's even remotely affecting the community at large I try my best to let potentially interested people know and give a heads-up and room for discussion on the mailing list, and it honestly pisses me off when others just secretly change the world overnight and then smugly sit on their fait accompli.
This change is very controversial and it's not clear that the majority of the community supports it. I'd like you to revert it until you can show that it does.
To view, visit change 31651. To unsubscribe, or for help writing mail filters, visit settings.