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

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 10:53 PM Sergei Trofimovich <slyfox@g.o> wrote:
>
> On Fri, 14 Sep 2018 19:40:13 +0300
> Alon Bar-Lev <alonbl@g.o> wrote:
>
> >
> > No dependency of toolchain nor annotations.
> > A strict policy of no warnings will require changes as dependencies
> > including toolchain are progressing.
> > This creates an overhead for selected packages.
> > A maintainer and the non-stable team should be able to know the package status.
> > Preferably this may be done by automation, I appreciate the work of
> > Toralf Förster with tinderbox to automate check various cases.
> > When a new slot of toolchain is available, maintainers should check
> > their packages in any case, there are other issues and side affects
> > that we experienced, especially in C++ packages.
> > For these packages usually there are 3 for each slot: the current
> > stable, the next stable and the non-stable, so the overhead is
> > constrained.
>
> Sorry. I'm afraid I missed your answer. I'll restate the question again:
>
>   If you do it then what is your workflow to fix breakages
>   appearing in stable packages caused by minor environment
>   changes like toolchain tweaks?
>
> I mean mechanically as a package maintainer.
>
> Since you did not mention it I see a few alternatives:
> - revbump a package with a backport of a local fix and fast-track
>   stabilization without usual soak time in ~arch

Fix in place if false positive.
Revision bump if positive.

> - pull new upstream version and fast-track stabilization without
>   usual soak time in ~arch

No reason to wait for upstream if obvious positive just like any bug fix.

> - no revbump, apply the patch as-is and hope it does not break
>   existing users.

Correct.

> - anything else?

Patching the package (stable and unstable) to remove -Werror if too
many of them and downstream maintainer reaches to a conclusion that
the overhead is too high and benefit is little and provide this
feedback to upstream to work together on a new release of upstream
which resolves all warnings with newer toolchain.

>
> > > Unused variable is a good example of typical benign warning:
> > > it was there all the time, it's not a new bug and does not
> > > warrant need for an immediate fix.
> >
> > Unused variable is a good example of CRITICAL potential issue
>
> I understand you point. I disagree with it.
>
> My litmus test: if behaviour of the package did not change after
> the fix then the issue was not real.

But how can you get the report to evaluate if it is real or not? I
fail to understand this argument that is repeated over and over.
Everyone is smart after the did... while we are looking for the
trigger to evaluate.

> > > Toolchain just happend to get better at control flow graph
> > > analysis. Fix can easily wait for next release and save
> > > everyone's time.
> >
> > Once again, the number of permutation of build and architecture may
> > reveal issues that are cannot be detected on maintainer machine.
> > If a fix is a real issue that is found in stable package, do you
> > suggest to wait for next release to save whose time?
>
> It's up to maintainer to decide on how to resolve the issue once
> maintainer understands the scope of the problem.

Correct. My believe is that it is up to maintainer to decide.

> > Once again I outlined the cases in which -Werror can be preserved, I
> > will repeat... (a) upstream has strict policy of no-warnings, (b)
> > upstream added -Werror, (c) downstream opinion is that upstream is
> > following the policy, (d) upstream is friendly, (e) downstream accepts
> > the potential maintenance overhead.
>
> Your proposal is clear. Thanks for restating it.
>
> I still think keeping -Werror enabled by default makes more harm
> than good.

Yes, but we are not talking about by default, right?

> > > Gentoo does not normally run tests on user's systems either.
> > > Tests are arguably a lot more precise in pointing out real
> > > problems in software.
> >
> > Correct. I believe that this may be revisit as well, for selected
> > packages in which tests are stable run them on user machines. There is
> > no reason why we cannot add a directive to ebuild to enable tests by
> > default and let user to disable this to save CPU/time of build.
>
> Additional thanks for considering an option to disable tests back.
>

Any mechanism that is fully supported by upstream and downstream
maintainer find it stable should be enabled by default. I do see the
benefit of disabling tests not because they may break as per the same
argument I would like to have these reported and investigated, but to
save resources (time and CPU) which may be significant.

Thanks,
Alon