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