| 1 |
On Sep 9, 2018, at 12:32 PM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
|
| 3 |
>>>>>> On Sun, 09 Sep 2018, Andrew Savchenko wrote: |
| 4 |
> |
| 5 |
>> What I'm trying to do is to allow maintainers to keep -Werror if |
| 6 |
>> they really want to do this, understand what they are doing and |
| 7 |
>> have enough manpower to support this. |
| 8 |
> |
| 9 |
> Bug 665464 has just proven that this doesn't work. That bug would not |
| 10 |
> have happened if the policy had been followed. Also its fix (removal of |
| 11 |
> an unused variable) should have been applied only upstream. I don't see |
| 12 |
> a good reason for adding downstream patches that will make no difference |
| 13 |
> for the resulting binary. At least not when the upstream package is |
| 14 |
> maintained, and the issue will likely go away with one of the next |
| 15 |
> releases. |
| 16 |
> |
| 17 |
>> As can be seen from aforementioned bugs right now developer and |
| 18 |
>> upstream support this to their best and yet QA team tries to |
| 19 |
>> enforce -Werror drop using the brute force and ignoring active best |
| 20 |
>> effort support. This should not happen. |
| 21 |
> |
| 22 |
> See flameeyes's old blog post for the rationale why the current policy |
| 23 |
> is in place: |
| 24 |
> https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/ |
| 25 |
For every pointless check that fails -Werror, there is likely one that actually does matter. An unused variable could go either way if upstream intended to use that variable, but used another one by mistake (it happens). |
| 26 |
|
| 27 |
Allowing users to opt into -Werror behavior on specific packages whose maintainers have a good reason to do it and are keeping up with things would be alright. |
| 28 |
> |
| 29 |
> Ulrich |
| 30 |
> |
Archives