On Fri, Sep 14, 2018 at 10:53 PM Sergei Trofimovich <sly...@gentoo.org> wrote: > > On Fri, 14 Sep 2018 19:40:13 +0300 > Alon Bar-Lev <alo...@gentoo.org> 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
