1 |
On Fri, 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 |
> |
17 |
> Other questions arise: Do we block stabilization of clang et al.? |
18 |
> |
19 |
|
20 |
Presumably we could make it a blocker, so then portage won't install |
21 |
the new stable toolchain. That buys time and only affects users of |
22 |
that particular package. But, as I pointed out before you can do that |
23 |
without using -Werror - just block installation with an unqualified |
24 |
toolchain. |
25 |
|
26 |
You would only use an approach like this for packages where QA was |
27 |
fairly important, so the inconvenience would be worth it. |
28 |
|
29 |
-- |
30 |
Rich |