1 |
On Fri, Sep 14, 2018 at 8:16 PM Richard Yao <ryao@g.o> wrote: |
2 |
> |
3 |
> On 09/14/2018 12:40 PM, Alon Bar-Lev wrote: |
4 |
> > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@g.o> wrote: |
5 |
> >> |
6 |
> >> On Tue, 11 Sep 2018 12:44:38 +0300 |
7 |
> >> Alon Bar-Lev <alonbl@g.o> wrote: |
8 |
> >> |
9 |
> >> I'm personally in favour of not allowing -Werror |
10 |
> >> to be in build system unconditionally. |
11 |
> >> |
12 |
> >> Maintainer is free to implement --enable-werror any way |
13 |
> >> it's convenient to run on their own extended sanity checks |
14 |
> >> and optionally expose it to users. Be it USE flag or |
15 |
> >> EXTRA_ECONF option. |
16 |
> > |
17 |
> > This discussion is not for downstream to have a more strict policy |
18 |
> > than upstream. People try to hijack discussion and introduce noise to |
19 |
> > de-focus the discussion. |
20 |
> > |
21 |
> > Downstream policy cannot be more strict than upstream as then every |
22 |
> > change upstream is doing downstream need to rebase and invest in even |
23 |
> > more changes. |
24 |
> > |
25 |
> > This discussion is to follow upstream strict policy if upstream proves |
26 |
> > that it stands behind it and downstream is willing to follow. |
27 |
> I don't think we should do that unless we provide a USE flag for users |
28 |
> to opt into the behavior. Forcing it on users is problematic for the |
29 |
> reasons others stated. However, letting them opt into the behavior is |
30 |
> reasonable. |
31 |
> |
32 |
> In the case of sys-fs/zfs, enabling -Werror (which includes -Wall) on |
33 |
> USE=debug is following upstream's wishes to build debug builds with -Werror. |
34 |
|
35 |
Let's do this the other way around and be react based on facts and not |
36 |
speculations. |
37 |
Let's change the policy for a year for selected packages as I |
38 |
outlined, monitor bugs and after a year see response times, affected |
39 |
users and if downstream patches are accumulated. Then we can decide if |
40 |
we need to patch upstream packages. |
41 |
If we need to patch upstream package anyway, not follow upstream |
42 |
policy and not accepting input for various of permutations and |
43 |
architecture from all users, this discussion is nearly void. |