On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote: > 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. >
...and for how long did you exactly ignore the standing policy that
suddenly we need a new testing period? How about we do the opposite
and you prove a *single* bug found downstream using this method so far?
Because so far this discussion is not much different than "let's make
the ebuild fail for some values of ${RANDOM}, and add extra values when
users complain". Though the variant with random has probably a greater
chance of failing when *actual* security issues happen.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
