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

[Sergei Trofimovich]

On Fri, 14 Sep 2018 19:40:13 +0300
Alon Bar-Lev <alonbl@g.o> 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.

Correct.

To clarify: I was talking only about packages with following properties:
1. existing -Werror enabled upstream by default (or unconditionally)
2. disabled by default downstream by default (WRT current policy)

Nothing more.

> > Do you intend to keep -Werror for case when ebuild goes
> > stable as well?
>
> Correct.
>
> > If you do it then what is your workflow to fix breakages
> > appearing in stable packages caused by minor environment
> > changes like toolchain tweaks?
>
> Correct.
>
> > Add another round of stabilization on each arch team? It
> > sounds like your default assumption that code needs to be
> > changed in a semantically significant way: add annotations
> > that might not like some toolchains, remove unused code.
>
> 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
- pull new upstream version and fast-track stabilization without
  usual soak time in ~arch
- no revbump, apply the patch as-is and hope it does not break
  existing users.
- anything else?

> > 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.

> > 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.

> 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.

> > 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.

-- 

  Sergei