Re: [gentoo-dev] Changing policy about -Werror

[Michał Górny]

On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote:
> On Fri, Sep 14, 2018 at 8:16 PM Richard Yao <ryao@g.o> wrote:
> >
> > On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@g.o> wrote:
> > > >
> > > > On Tue, 11 Sep 2018 12:44:38 +0300
> > > > Alon Bar-Lev <alonbl@g.o> 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