As someone in a DevOps role who has three times been the steward of major migrations between baseline OS versions, I have often been frustrated at teams who have hard-coded -Werror into their build configs, thus forcing me to jump through hoops to patching it out because the new compiler has some trivial complaint about this or that and the build is uncompileable on the new target.
I understand the noble goal of being warning-clean, but I wish there was a way to implement it in such a way that it could also be globally disabled. Then I could get a top level build, but the local resolution of the issues would still be on the owners of the code.
In the case of the team moving to a new compiler, what are you suggesting? We can’t merge in use of a newer compiler until there are zero warnings in all our products? Who “fixes” all those code bases? Who touches the pieces of code that were last touched 5 or 10 years ago?
Various solutions are possible, including the obvious one of just removing -Werror. But the point is that this decision should be made by the team that owns/maintains the code, not by some centralized devops group.
I understand the noble goal of being warning-clean, but I wish there was a way to implement it in such a way that it could also be globally disabled. Then I could get a top level build, but the local resolution of the issues would still be on the owners of the code.