| 1 |
> On Sep 14, 2018, at 3:29 PM, Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> |
| 3 |
>> On 09/14/2018 01:52 PM, Rich Freeman wrote: |
| 4 |
>> |
| 5 |
>> Wouldn't the flip side of this be demonstrating that this has actually |
| 6 |
>> caused issues? If following upstream discovers no bugs and also |
| 7 |
>> causes no issues, why not leave it to maintainer discretion? |
| 8 |
>> |
| 9 |
> |
| 10 |
> We know it causes issues, there are hundreds of bugs about it (bugzilla |
| 11 |
> stops counting at 500 on a search for "Werror"). |
| 12 |
> |
| 13 |
> No one has answered the question: what do you do when a stable package |
| 14 |
> breaks because of a new warning? |
| 15 |
> |
| 16 |
> If there's no answer to that question that doesn't involve making an |
| 17 |
> unofficial in-place downstream-only edit to a piece of code that is (by |
| 18 |
> the opposing argument) intensely security-critical in a stable package, |
| 19 |
> then we're all wasting our time talking about this. |
| 20 |
Wouldn’t this be largely covered as part of GCC stabilization? We could reserve the right to kill -Werror in a package where it blocks GCC stabilization if the maintainer does not handle it in a timely manner. |
| 21 |
> |
Archives