1 |
> On Sep 14, 2018, at 4:20 PM, Michael Orlitzky <mjo@g.o> wrote: |
2 |
> |
3 |
> On 09/14/2018 03:58 PM, Richard Yao wrote: |
4 |
>>> |
5 |
>>> No one has answered the question: what do you do when a stable package |
6 |
>>> breaks because of a new warning? |
7 |
>>> |
8 |
>>> ...> |
9 |
>> 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. |
10 |
>>> |
11 |
> |
12 |
> They would be uncovered during GCC stabilization, but then you're right |
13 |
> back in the original situation: how do you fix the stable package? The |
14 |
> only answer that doesn't violate some other policy is to patch it in a |
15 |
> new revision and wait for it to stabilize again. |
16 |
This depends on the issue. |
17 |
> |
18 |
> Other questions arise: Do we block stabilization of clang et al.? |
19 |
We probably should start doing that once Clang is able to build everything, but someone would need to volunteer to handle it. It is a big job. |
20 |
> |
21 |
> If we can simply remove -Werror because it's been a month, were the |
22 |
> warnings ever really important to begin with? |
23 |
That was a suggestion to handle maintainer non-response. You can already do whatever you want if the maintainer is non-responsive after telling him in a bug that you will do something if a response is not made in a reasonable period (e.g. 2 weeks). I am just pointing it out. |
24 |
> |
25 |
> How many packages do we want to make the toolchain team stop and fix |
26 |
> before they can do their jobs? |
27 |
Presumably, the maintainers would handle this. If they cannot, they should not be honoring upstream’s -Werror policy. |