coding_standard.md: Relax warning as error on release (opensource)

[rzr]

This is a "user oriented" best practice used in many FLOSS projects. Fixing at least one supported env is good, but maybe not enough, extending support can help but will it scale?

Reality of sofware engineering is that software integration is a moving science, constraints are evolving over space and time. We can't anticipate (future) breakage,
this change can mitigate the annoyance and maximize user adoption, help integrators and ease software maintenance.

The alternative option, would be to wait user(s) to complain and provide support for the desired env in an acceptable time frame.

[conq]

I disagree with this. I don't see the motivation behind this.

[rzr]

The motivation applies specifically when producing opensource software (shared code will be rebuild in a different env)

Not about the code we build and deliver as binaries

ok I can explain more but let others read what I initially proposed.

[jrosenberger]

I also disagree with this. If someone is building code on a new compiler that's stricter, they can always turn the warnings off themselves. They should do this knowingly rather than have us quietly do it for everyone.

[rzr]

If someone is building code on a new compiler that's stricter, they can always turn the warnings off themselves.

So this mean encouraging them to patch the released code, I am not in favor of downstream patches if it can be avoided,.

BTW IMHO we are making some assumptions here:

• User has time to figure it out how to disable it (and not give up on 1st try or rant about it)
• And will not try to fix the warning themselves downstream (and potentially break things and then ask for support)
• User will try to upstream a fix and maintainers are willing to integrate it for an upcoming release (that will satisfy user needs until the next break)

[jrosenberger]

There is already a statement in the preceding paragraph that says "This applies to builds that are part of "make test". It does not apply to build mechanisms passed through to other projects."

I think if CI builds etc all run with Werror but the released code doesn't by default, I think that's fine. A conscious official choice like this is better than turning it on and off in random commits.

[jerome-pouiller]

This applies to builds that are part of "make test". It does not apply to build mechanisms passed through to other projects.

I think the document does not explain the drawbacks of always enforcing -Werror. The sentence above make think that always enforcing -Werror is not mandatory but is a good thing to do.

I suggest:

CI, SQA, tests and developers should compile with `-Werror` and report failures as bugs.

However, it is very difficult to ensure a code will never cause any warning with any 
compiler. Especially if we consider we don't know what warning will be introduced in the 
future compilers. The flag `-Werror` must not be enforced for the final consumer of the code.

[rzr]

Thank you for your feedback, it is interesting to see that this change is controversial (what is the priority our process or our users or a tradeoff ? , less provocatively can we satisfy our SDK users AND our "out of SDK" users ?)

Let's clarify, First let's try to see if we manage to reach a consensus on the final goal when producing OSS:

User/Integrator should be able to rebuild the released code without tweaking it for an unsupported env.

It is highly probable that the component will work as good, but just trigger warnings which is useful for developers not integrator (as I said previously it is a different mindset)

Please vote:

• 👍 It is a valuable goal, support the idea
• 👎 It will cause more problems (please explain)
• 👁️ no strong opinion yet (need more inputs)