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