1 |
On Sat, Sep 15, 2018 at 12:02 AM Fabian Groffen <grobian@g.o> wrote: |
2 |
> |
3 |
> On 14-09-2018 16:29:43 -0400, Rich Freeman wrote: |
4 |
> > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky <mjo@g.o> wrote: |
5 |
> > > |
6 |
> > > On 09/14/2018 03:58 PM, Richard Yao wrote: |
7 |
> > > >> |
8 |
> > > >> No one has answered the question: what do you do when a stable package |
9 |
> > > >> breaks because of a new warning? |
10 |
> > > >> |
11 |
> > > >> ...> |
12 |
> > > > 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. |
13 |
> > > >> |
14 |
> > > |
15 |
> > > They would be uncovered during GCC stabilization, but then you're right |
16 |
> > > back in the original situation: how do you fix the stable package? The |
17 |
> > > only answer that doesn't violate some other policy is to patch it in a |
18 |
> > > new revision and wait for it to stabilize again. |
19 |
> > > |
20 |
> > > Other questions arise: Do we block stabilization of clang et al.? |
21 |
> > > |
22 |
> > |
23 |
> > Presumably we could make it a blocker, so then portage won't install |
24 |
> > the new stable toolchain. That buys time and only affects users of |
25 |
> > that particular package. But, as I pointed out before you can do that |
26 |
> > without using -Werror - just block installation with an unqualified |
27 |
> > toolchain. |
28 |
> > |
29 |
> > You would only use an approach like this for packages where QA was |
30 |
> > fairly important, so the inconvenience would be worth it. |
31 |
> |
32 |
> Perhaps, if one persists on going this route, only do this for platforms |
33 |
> that upstream supports, such that arches which will suffer from this |
34 |
> (typically ppc, sparc, ...) don't have to be blocked by this. |
35 |
|
36 |
Exactly in these cases the -Werror is useful as if upstream expects no |
37 |
warnings then any warning should block installation and trigger bug |
38 |
report. In Gentoo in many cases we use packages on platform has no |
39 |
access to, our feedback to upstream is valuable. A great example is |
40 |
gnutls in which we collectively (maintainer, unstable users, |
41 |
architecture teams, stable users) found issues on architectures that |
42 |
almost nobody other than Gentoo has access to. |