graesslin added a comment.
The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error. Thus I suggest that those who think this should be the default for all projects by KDE do the work to run clang-tidy over the complete KDE code base and afterwards enable this warning. I'm just not happy with the approach of breaking workflow without any discussion at all with the larger community. We have points in time where we can break things. E.g. the upcoming Qt 6. What I do not like is breaking in the middle of a release cycle without any coordination. Also I don't want to spend my very little spare time hunting behind what broke KWin build. I'm really not pleased about this from above attitude to break the compile of projects. It's one of the "dann macht euren Scheiss doch selbst" moments. Btw. of course KWin is fully maintained - also the old xcb code. It's just not possible to review 500+ line changes with someone adding override. Furthermore we have here virtuals which nobody touched for 15 years, but git blame on them is super important. And if you wonder: we have 1555 override in KWin. We use the new possibilities. We just don't adjust the old code base which nobody touches. I'm sure you all will be the first one to yell if KWin breaks and renders your desktop unusable. Yes we have very strict requirements on stability. A change for the sake of change is not done in KWin. So please revert this change and do a proper approach, talk to the community, ensure that this doesn't cause any new warnings and thus make it a useful new warning. In the current state it only causes work without any benefits for KWin. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D18167 To: aacid Cc: kossebau, graesslin, apol, vkrause, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns
