Changing policy about -Werror

classic Classic list List threaded Threaded
119 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2


> On Sep 13, 2018, at 12:03 PM, Fabian Groffen <[hidden email]> wrote:
>
>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>
>>
>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
>>>>
>>>> On 2018-09-12 16:50, Rich Freeman wrote:
>>>> There is also the case where we want these warnings to block
>>>> installation, because the risk of there being a problem is too great.
>>>
>>> I really disagree with that. So many devs have already said multiple
>>> times in this thread that "-Werror" is only turning existing warnings
>>> into fatal errors but "-Werror" itself doesn't add any new checks and
>>> more often requires "-O3" to be useful.
>> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.
>
> Huh?  -O3 enables more checks, which can generate more warnings.

What checks are those? -O3 affects backend optimization while warnings are generated by the front end. Once the immediate representation is generated, there are no other warnings aside from those from the linker.

>  -O3
> isn't "needed", but if upstream is so interested in clean and correct
> code, they should've fixed all warnings in the first place and thus
> enabled all of them.  In fact, I expect every sane upstream to use "-O3
> -Wall -Werror" in one of their automated builds.  Not that this catches
> anything useful on x86{,_64} when there is for instance use of signed
> and unsigned char types, so it isn't conclusive.
>
> The whole point in here is that -Werror doesn't add much if you care.
> The whole point why it is not desired in Gentoo is that users don't
> necessarily are developers, or even interested in fixing warnings --
> regardless whether they point to real problems or not.
>
> If there are real problems in a package (exposed by a compiler or not)
> then this should ideally stand out during ~arch testing, or even before
> when the Gentoo maintainer examines the build (might even use -Werror
> for his own purposes).  If such code ends up in stable arch we just made
> a stabilisation mistake, or got royally messed up by upstream, depending
> how you look at it.
>
> Fabian
>
> --
> Fabian Groffen
> Gentoo on a different level


Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Matt Turner-5
On Thu, Sep 13, 2018 at 4:13 PM Richard Yao <[hidden email]> wrote:

> > On Sep 13, 2018, at 12:03 PM, Fabian Groffen <[hidden email]> wrote:
> >
> >> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
> >>
> >>
> >>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
> >>>>
> >>>> On 2018-09-12 16:50, Rich Freeman wrote:
> >>>> There is also the case where we want these warnings to block
> >>>> installation, because the risk of there being a problem is too great.
> >>>
> >>> I really disagree with that. So many devs have already said multiple
> >>> times in this thread that "-Werror" is only turning existing warnings
> >>> into fatal errors but "-Werror" itself doesn't add any new checks and
> >>> more often requires "-O3" to be useful.
> >> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.
> >
> > Huh?  -O3 enables more checks, which can generate more warnings.
>
> What checks are those? -O3 affects backend optimization while warnings are generated by the front end. Once the immediate representation is generated, there are no other warnings aside from those from the linker.

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

Search for "depend on"

-> [...] estimated based on heuristics that depend on thelevel
argument and on optimization

-> Because these warnings depend on optimization [...]

Yes, warnings are dependent on optimization level.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Georg Rudoy
In reply to this post by Fabian Groffen-2
On 13.09.2018 at 16:20 user Fabian Groffen <[hidden email]> wrote:
>> > To illustrate harmless:
>> >   warning: this statement may fall through [-Wimplicit-fallthrough=]
>> > The warning message already has it in it that it's just a pure guess.
>>
>> One that exposed a lot of unintentional fallthoughs which were fixed
>> when reporting to upstream.
>
> Sure that's why the warning is there.  But you ignore the point that the
> same code compiled fine and ran fine for years without problems.

I have more than a few examples of my code compiling fine and running "fine"
for years (so that no observable defects were visible), yet newly introduced
warnings or static analyzer runs showed the defects that resolved actual bugs
when fixed. And, ironically, that also includes the fallthrough
warnings [1-3].

And cases of me stumbling upon some other legacy code, compiling it with a
newer compiler and going "WTF how it even managed to produce anything meaningful
at all?" are not uncommon.

Just my two C++ents here.

[1] https://github.com/0xd34df00d/leechcraft/commit/663b69249cd61d1cbd490a3eee7909ae26d03240
[2] https://github.com/0xd34df00d/leechcraft/commit/fa8ff9dc315e894fada4aaf73534bdfc15121cb3
[3] https://github.com/0xd34df00d/leechcraft/commit/6b26961b52b6e8277db39b084f483d1959253313


--
  Georg Rudoy


Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2
In reply to this post by Matt Turner-5


> On Sep 13, 2018, at 7:21 PM, Matt Turner <[hidden email]> wrote:
>
> On Thu, Sep 13, 2018 at 4:13 PM Richard Yao <[hidden email]> wrote:
>>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen <[hidden email]> wrote:
>>>
>>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>>>
>>>>
>>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
>>>>>>
>>>>>> On 2018-09-12 16:50, Rich Freeman wrote:
>>>>>> There is also the case where we want these warnings to block
>>>>>> installation, because the risk of there being a problem is too great.
>>>>>
>>>>> I really disagree with that. So many devs have already said multiple
>>>>> times in this thread that "-Werror" is only turning existing warnings
>>>>> into fatal errors but "-Werror" itself doesn't add any new checks and
>>>>> more often requires "-O3" to be useful.
>>>> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.
>>>
>>> Huh?  -O3 enables more checks, which can generate more warnings.
>>
>> What checks are those? -O3 affects backend optimization while warnings are generated by the front end. Once the immediate representation is generated, there are no other warnings aside from those from the linker.
>
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
>
> Search for "depend on"
>
> -> [...] estimated based on heuristics that depend on thelevel
> argument and on optimization
>
> -> Because these warnings depend on optimization [...]
>
> Yes, warnings are dependent on optimization level.

There are three such options. The first two are for format statements:

> “When the exact number of bytes written by a format directive cannot be determined at compile-time it is estimated based on heuristics that depend on the level argument and on optimization. While enabling optimization will in most cases improve the accuracy of the warning, it may also result in false positives. “

My read of this is that the warning occurs regardless of optimization level, but it could somehow be improved by optimization.

As for the last, it is for uninitialized variable reads. However, I think you are misinterpreting the claim. The way that optimization level could affect warning generation would be if the warning generation came after optimization passes that could hide reads. That means that -O3 would prevent the warning.

This is a really odd design decision by the GCC developers. With other compilers, the separation between front end and backend is strong enough that you will never have this sort of thing. It does not seem necessary to me either. :/

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Georg Rudoy
On 14.09.2018 at 0:44 user Richard Yao <[hidden email]> wrote:
> This is a really odd design decision by the GCC developers. With other compilers, the separation between front end and backend is strong enough that you will never have this sort of thing. It does not seem necessary to me either. :/

You might be able to perform certain additional data/control flow analysis after things like inlining, dead code removal or devirtualization.

Moving that logic to the frontend would require essentially duplicating what's the optimizer's gonna do anyway, which might have negative effects on compilation times (both with and without optimizations) and compiler code maintenance.

BTW I'm not sure the separation on backend/frontend makes sense for modern C++ compilers. clang surely does some optimizations, and llvm (at least, in theory) is certainly able to find certain issues after more optimizer passes.



--
  Georg Rudoy


Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Matt Turner-5
In reply to this post by Richard Yao-2
On Thu, Sep 13, 2018 at 5:44 PM Richard Yao <[hidden email]> wrote:

> > On Sep 13, 2018, at 7:21 PM, Matt Turner <[hidden email]> wrote:
> >
> > On Thu, Sep 13, 2018 at 4:13 PM Richard Yao <[hidden email]> wrote:
> >>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen <[hidden email]> wrote:
> >>>
> >>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
> >>>>
> >>>>
> >>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
> >>>>>>
> >>>>>> On 2018-09-12 16:50, Rich Freeman wrote:
> >>>>>> There is also the case where we want these warnings to block
> >>>>>> installation, because the risk of there being a problem is too great.
> >>>>>
> >>>>> I really disagree with that. So many devs have already said multiple
> >>>>> times in this thread that "-Werror" is only turning existing warnings
> >>>>> into fatal errors but "-Werror" itself doesn't add any new checks and
> >>>>> more often requires "-O3" to be useful.
> >>>> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.
> >>>
> >>> Huh?  -O3 enables more checks, which can generate more warnings.
> >>
> >> What checks are those? -O3 affects backend optimization while warnings are generated by the front end. Once the immediate representation is generated, there are no other warnings aside from those from the linker.
> >
> > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> >
> > Search for "depend on"
> >
> > -> [...] estimated based on heuristics that depend on thelevel
> > argument and on optimization
> >
> > -> Because these warnings depend on optimization [...]
> >
> > Yes, warnings are dependent on optimization level.
>
> There are three such options. The first two are for format statements:
>
> > “When the exact number of bytes written by a format directive cannot be determined at compile-time it is estimated based on heuristics that depend on the level argument and on optimization. While enabling optimization will in most cases improve the accuracy of the warning, it may also result in false positives. “
>
> My read of this is that the warning occurs regardless of optimization level, but it could somehow be improved by optimization.
>
> As for the last, it is for uninitialized variable reads. However, I think you are misinterpreting the claim. The way that optimization level could affect warning generation would be if the warning generation came after optimization passes that could hide reads. That means that -O3 would prevent the warning.
>
> This is a really odd design decision by the GCC developers. With other compilers, the separation between front end and backend is strong enough that you will never have this sort of thing. It does not seem necessary to me either. :/

I'm sorry, but you really don't know what you're talking about. I've
already told you once that you were just adding noise to this
conversation.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2


> On Sep 13, 2018, at 11:35 PM, Matt Turner <[hidden email]> wrote:
>
> On Thu, Sep 13, 2018 at 5:44 PM Richard Yao <[hidden email]> wrote:
>>> On Sep 13, 2018, at 7:21 PM, Matt Turner <[hidden email]> wrote:
>>>
>>> On Thu, Sep 13, 2018 at 4:13 PM Richard Yao <[hidden email]> wrote:
>>>>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen <[hidden email]> wrote:
>>>>>
>>>>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>>>>>
>>>>>>
>>>>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> On 2018-09-12 16:50, Rich Freeman wrote:
>>>>>>>> There is also the case where we want these warnings to block
>>>>>>>> installation, because the risk of there being a problem is too great.
>>>>>>>
>>>>>>> I really disagree with that. So many devs have already said multiple
>>>>>>> times in this thread that "-Werror" is only turning existing warnings
>>>>>>> into fatal errors but "-Werror" itself doesn't add any new checks and
>>>>>>> more often requires "-O3" to be useful.
>>>>>> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.
>>>>>
>>>>> Huh?  -O3 enables more checks, which can generate more warnings.
>>>>
>>>> What checks are those? -O3 affects backend optimization while warnings are generated by the front end. Once the immediate representation is generated, there are no other warnings aside from those from the linker.
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
>>>
>>> Search for "depend on"
>>>
>>> -> [...] estimated based on heuristics that depend on thelevel
>>> argument and on optimization
>>>
>>> -> Because these warnings depend on optimization [...]
>>>
>>> Yes, warnings are dependent on optimization level.
>>
>> There are three such options. The first two are for format statements:
>>
>>> “When the exact number of bytes written by a format directive cannot be determined at compile-time it is estimated based on heuristics that depend on the level argument and on optimization. While enabling optimization will in most cases improve the accuracy of the warning, it may also result in false positives. “
>>
>> My read of this is that the warning occurs regardless of optimization level, but it could somehow be improved by optimization.
>>
>> As for the last, it is for uninitialized variable reads. However, I think you are misinterpreting the claim. The way that optimization level could affect warning generation would be if the warning generation came after optimization passes that could hide reads. That means that -O3 would prevent the warning.
>>
>> This is a really odd design decision by the GCC developers. With other compilers, the separation between front end and backend is strong enough that you will never have this sort of thing. It does not seem necessary to me either. :/
>
> I'm sorry, but you really don't know what you're talking about.

Either provide code examples that generate warnings in a way that demonstrates that I am incorrect or withdraw that ad hominem.

> I've
> already told you once that you were just adding noise to this
> conversation.
I can understand the remarks about USE=debug being considered noise given that people seem to think that -Werror is a boolean thing where it is either on for any combination of USE flags or off for any combination of USE flags. However, discussing how compiler internals impacts how -Werror works is definitely not noise.

You cannot have a discussion about how -Werror should be handled without understanding what I actually does.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Alon Bar-Lev-2
In reply to this post by Sergei Trofimovich-6
On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <[hidden email]> wrote:

>
> On Tue, 11 Sep 2018 12:44:38 +0300
> Alon Bar-Lev <[hidden email]> 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.

For your question: No. Downstream should not add -Werror to upstream
package, not in a parameter or USE flag, as this will probably break
and cause a queue of downstream patches.

> > I would like to suggest a modify our policy with the following
> > exception clause: Package maintainer may decide to keep upstream
> > -Werror as long as he is willing to resolve all issues resulting from
> > -Werror as if it was a blocker bug.
>
> 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.

> Or patch package in-place without bumping? None of options
> sound optimal compared to dropping -Werror.

Success of build is not the only concern although I see people here
that are interested only in that.
Patching upstream package and/or change upstream quality policy is
something that we should avoid as well to maintain upstream warranty.

> > The package maintainer decision may be based on the package state and
> > the relationship with upstream, but basically, it is his decision as
> > long as issues are fixed in timely manner, it is his overhead after
> > all.
>
> I agree that maintainer's will and upstream's will should be
> respected and it's not something needs to be absolutely
> enforced all the time.
>
> Personally I disagree -Werror on end-user machine is worth
> it (or cppcheck, or coverity round-trip run is worth running
> on user's machine unconditionally).
>
> 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, the bug
that triggered this this discussion has a return code that was not
used. The permutation was not tested by upstream as it rarely used, it
was not tested by me either by the same reason, both is a mistake.
Fortunately, someone else tested this permutation and his build
failed, triggered a bug. If -Werror has not been used we would not
have known about this issue. In many cases these happen in
architecture that maintainer nor upstream have access to. In this
specific case I went over the code history to the time the return code
have been used and determined that this indeed should be ignored,
imagine the opposite. A patch was submitted to upstream to confirm
resolution as any issue in code, upstream confirmed and merged this in
timely fashion. Bottom line we all (Gentoo, upstream and any other
distribution) enjoy better quality.

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

> Not every user is willing to create bugzilla account and figure
> the path of reporting the breakage. Especially if there are
> many breakages like that. Getting multiple various errors is
> probable if one imagines -Werror to be commonly allowed.
> This is user's overhead. Not just maintainer's.

Most of these issues are detected early at process by unstable users
which are opening bugs.

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.

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

> > ARGUMENT: If a package compiled in the past using toolchain X then it
> > must continue to do so with any future toolchain.
> >
> > I do not understand when "build" is the test for runtime
>
> The argument was about "keep compiling". Runtime
> behaviour is a separate issue and (in my opinion) is an
> orthogonal topic.
>
> On another note I occasionally like to build Gentoo with
> clang's -Weverything (or equivalent set of gcc CFLAGS)
> to get the idea if there is a good useful warning out there
> to put into -Werror= list.
>
> Explicit -Werror= list allows code not to regress. But even
> that is prone to harmless infelicities in libc headers that
> can't be easily fixed.
>
> In case of opensc it just does not compile even if I pass -Wno-error:
>     $ CC=clang CFLAGS="-O2 -Weverything -Wno-error" emerge -v1 opensc
>
> I don't expect 'opensc' upstream to fix this use for me
> and don't see it worth reporting to bugzilla.
>
> But maybe I'm wrong?

When downstream maintainer create healthy relationship with upstream,
and when mutual interest is to support clang then working together to
improve upstream support of clang instead doing that at downstream is
much better solution to the entire open source eco-system.

Regards,
Alon

Reply | Threaded
Open this post in threaded view
|

Changing policy about -Werror

Richard Yao-2
In reply to this post by Georg Rudoy


> On Sep 13, 2018, at 8:54 PM, Georg Rudoy <[hidden email]> wrote:
>
>> On 14.09.2018 at 0:44 user Richard Yao <[hidden email]> wrote:
>> This is a really odd design decision by the GCC developers. With other compilers, the separation between front end and backend is strong enough that you will never have this sort of thing. It does not seem necessary to me either. :/
I didn't want to get into this, but GCC's backend is actually split into
a middle-end, that does architecture independent optimizations and a
backend, that generates assembly code (and likely does architecture
specific optimization):

https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GNU_C_Compiler_Architecture

You can get it to dump what appears to be the input to the middle end by
doing -fdump-translation-unit. You can get GCC to dump each stage of the
middle end using -fdump-tree-all. Presumably, any warnings that depend
on optimization won't be generated, although someone would need to study
the code to verify that.

I suspect quite a few people talking about what -Werror -Wall does have
never actually touched the internals of a compiler and perhaps that
should change. I won't claim to be an expert, but I have minor
experience with front-end development, writing code to do error
generation, etcetera. Honestly, when I first looked at GCC's sources, I
decided that I would be happier never looking at them ever again, but I
am starting to reconsider that decision.
>
> You might be able to perform certain additional data/control flow analysis after things like inlining, dead code removal or devirtualization.
Do you have any examples? I am having some trouble making a test case
that shows a different in behavior at different optimization levels
either way.

Here is an example:

__attribute__((always_inline))
static inline int
test(int x) {
        return x;
}

int main() {
        int x;

        return (test(x)*0);
}

GCC 7.3.0 will emit a warning regardless of optimization level provided
that -Wall is passed. However, it will not emit a warning for this at
any optimization level:

int main() {
        int x;

        return (x*0);
}

>
> Moving that logic to the frontend would require essentially duplicating what's the optimizer's gonna do anyway, which might have negative effects on compilation times (both with and without optimizations) and compiler code maintenance.
If it is easier to use the optimizer's infrastructure to figure this
out, then the code could be written to call it to do analysis as a
pseudo-optimization pass, which GCC actually appears to do when it runs
its "Function test" "optimization" pass. There is no code maintenance
burden.

Fabian was right about needing -Wall for -Werror to catch many things
because most warnings are off by default. However, I am extremely
skeptical that the optimization level has significant error. -Wall gives
us whatever we need and so far, I cannot find a code example showing
differences in warning generation at different optimization levels. I'll
accept the idea that the warning quality might change (although I don't
fully understand the reasoning for it) by the GCC documentation.

However, I find the idea that -O3 will make a warning appear that didn't
otherwise appear to be very difficult to accept. The documentation
claims that optimization passes can effect emission of warnings for
uninitialized variables, but the only way that I could imagine that
happening would be if an optimization pass made x*0 into 0 before the
code generating the warning is run. This is the complete opposite of
what is being claimed here. In some actual tests, I am unable to get GCC
to emit a warning for that at any optimization level. I am also unable
to get it to behave differently for uninitialized variables at different
optimization levels no matter what idea I try.
>
>
>
> --
>  Georg Rudoy
>
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2
In reply to this post by Alon Bar-Lev-2
On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:

> On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <[hidden email]> wrote:
>>
>> On Tue, 11 Sep 2018 12:44:38 +0300
>> Alon Bar-Lev <[hidden email]> 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.

>
> For your question: No. Downstream should not add -Werror to upstream
> package, not in a parameter or USE flag, as this will probably break
> and cause a queue of downstream patches.
>
>>> I would like to suggest a modify our policy with the following
>>> exception clause: Package maintainer may decide to keep upstream
>>> -Werror as long as he is willing to resolve all issues resulting from
>>> -Werror as if it was a blocker bug.
>>
>> 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.
>
>> Or patch package in-place without bumping? None of options
>> sound optimal compared to dropping -Werror.
>
> Success of build is not the only concern although I see people here
> that are interested only in that.
> Patching upstream package and/or change upstream quality policy is
> something that we should avoid as well to maintain upstream warranty.
>
>>> The package maintainer decision may be based on the package state and
>>> the relationship with upstream, but basically, it is his decision as
>>> long as issues are fixed in timely manner, it is his overhead after
>>> all.
>>
>> I agree that maintainer's will and upstream's will should be
>> respected and it's not something needs to be absolutely
>> enforced all the time.
>>
>> Personally I disagree -Werror on end-user machine is worth
>> it (or cppcheck, or coverity round-trip run is worth running
>> on user's machine unconditionally).
>>
>> 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, the bug
> that triggered this this discussion has a return code that was not
> used. The permutation was not tested by upstream as it rarely used, it
> was not tested by me either by the same reason, both is a mistake.
> Fortunately, someone else tested this permutation and his build
> failed, triggered a bug. If -Werror has not been used we would not
> have known about this issue. In many cases these happen in
> architecture that maintainer nor upstream have access to. In this
> specific case I went over the code history to the time the return code
> have been used and determined that this indeed should be ignored,
> imagine the opposite. A patch was submitted to upstream to confirm
> resolution as any issue in code, upstream confirmed and merged this in
> timely fashion. Bottom line we all (Gentoo, upstream and any other
> distribution) enjoy better quality.
>
>> 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?
>
>> Not every user is willing to create bugzilla account and figure
>> the path of reporting the breakage. Especially if there are
>> many breakages like that. Getting multiple various errors is
>> probable if one imagines -Werror to be commonly allowed.
>> This is user's overhead. Not just maintainer's.
>
> Most of these issues are detected early at process by unstable users
> which are opening bugs.
>
> 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.
>
>> 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.
>
>>> ARGUMENT: If a package compiled in the past using toolchain X then it
>>> must continue to do so with any future toolchain.
>>>
>>> I do not understand when "build" is the test for runtime
>>
>> The argument was about "keep compiling". Runtime
>> behaviour is a separate issue and (in my opinion) is an
>> orthogonal topic.
>>
>> On another note I occasionally like to build Gentoo with
>> clang's -Weverything (or equivalent set of gcc CFLAGS)
>> to get the idea if there is a good useful warning out there
>> to put into -Werror= list.
>>
>> Explicit -Werror= list allows code not to regress. But even
>> that is prone to harmless infelicities in libc headers that
>> can't be easily fixed.
>>
>> In case of opensc it just does not compile even if I pass -Wno-error:
>>     $ CC=clang CFLAGS="-O2 -Weverything -Wno-error" emerge -v1 opensc
>>
>> I don't expect 'opensc' upstream to fix this use for me
>> and don't see it worth reporting to bugzilla.
>>
>> But maybe I'm wrong?
>
> When downstream maintainer create healthy relationship with upstream,
> and when mutual interest is to support clang then working together to
> improve upstream support of clang instead doing that at downstream is
> much better solution to the entire open source eco-system.
>
> Regards,
> Alon
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Alon Bar-Lev-2
On Fri, Sep 14, 2018 at 8:16 PM Richard Yao <[hidden email]> wrote:

>
> On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <[hidden email]> wrote:
> >>
> >> On Tue, 11 Sep 2018 12:44:38 +0300
> >> Alon Bar-Lev <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Rich Freeman
On Fri, Sep 14, 2018 at 1:22 PM Alon Bar-Lev <[hidden email]> wrote:
>
> 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.

Obviously up to QA/Council, but I think this sounds like a practical
approach.  No need to "change the policy" so much as approve a
temporary exception, perhaps for a defined period of time.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Michał Górny-5
In reply to this post by Alon Bar-Lev-2
On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote:

> On Fri, Sep 14, 2018 at 8:16 PM Richard Yao <[hidden email]> wrote:
> >
> > On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <[hidden email]> wrote:
> > > >
> > > > On Tue, 11 Sep 2018 12:44:38 +0300
> > > > Alon Bar-Lev <[hidden email]> 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

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2
In reply to this post by Fabian Groffen-2
On 09/13/2018 12:03 PM, Fabian Groffen wrote:

> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
>>
>>
>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
>>>
>>>> On 2018-09-12 16:50, Rich Freeman wrote:
>>>> There is also the case where we want these warnings to block
>>>> installation, because the risk of there being a problem is too great.
>>>
>>> I really disagree with that. So many devs have already said multiple
>>> times in this thread that "-Werror" is only turning existing warnings
>>> into fatal errors but "-Werror" itself doesn't add any new checks and
>>> more often requires "-O3" to be useful.
>> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.
>
> Huh?  -O3 enables more checks, which can generate more warnings.  -O3
> isn't "needed", but if upstream is so interested in clean and correct
> code, they should've fixed all warnings in the first place and thus
> enabled all of them.
That wasn't how I read this:

> Also, consider that for -Werror to be "better", you also need -O3 in
order to activate the "proper" compiler checks like "variable set but
never used" ones.

But I'll accept that I misunderstood.

> In fact, I expect every sane upstream to use "-O3
> -Wall -Werror" in one of their automated builds.  Not that this catches
> anything useful on x86{,_64} when there is for instance use of signed
> and unsigned char types, so it isn't conclusive.
>
> The whole point in here is that -Werror doesn't add much if you care.
> The whole point why it is not desired in Gentoo is that users don't
> necessarily are developers, or even interested in fixing warnings --
> regardless whether they point to real problems or not.
>
> If there are real problems in a package (exposed by a compiler or not)
> then this should ideally stand out during ~arch testing, or even before
> when the Gentoo maintainer examines the build (might even use -Werror
> for his own purposes).  If such code ends up in stable arch we just made
> a stabilisation mistake, or got royally messed up by upstream, depending
> how you look at it.
>
> Fabian
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Alon Bar-Lev-2
In reply to this post by Michał Górny-5
On Fri, Sep 14, 2018 at 8:33 PM Michał Górny <[hidden email]> wrote:

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

OK, back to personal discussion, unfortunately you question this in
this principal thread.

Personal response:
In all my years in Gentoo, I've never thought the maintainer lose his
judgement of how to maintain a package as long as the he/she provide a
great service to users.
I've never thought or read this (and other) paragraph as a strict
white and black nor the holy bible , but a suggestion of how to
provide a great service to user with the least overhead to maintainer,
the best practice, the common case.
I believe there was no complains from users about these packages, on
the opposite users report issues and are happy when resolved after
proper investigation.
I guess something had changed recently in Gentoo in which QA try to
take the maintainer judgement try to enforce a black and white
perspective and without looking at bug history and other sources.
I believe this is a regression and not a progression, I was very
disappointed to see this new side of Gentoo in which common sense for
a specific case cannot be discussed individually, nor that a fixed bug
is hijacked to discuss a principal issue without opening a separate
formal QA request to discuss properly, address some of the argument
raised by fellow developers and the reaction of requesting to ban
developers without any mature discussion. As you can see this in this
thread is not black and white.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Rich Freeman
In reply to this post by Michał Górny-5
On Fri, Sep 14, 2018 at 1:33 PM Michał Górny <[hidden email]> wrote:

>
> On Fri, 2018-09-14 at 20:22 +0300, Alon Bar-Lev wrote:
> > 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?

Wouldn't the flip side of this be demonstrating that this has actually
caused issues?  If following upstream discovers no bugs and also
causes no issues, why not leave it to maintainer discretion?

I'm not talking about hypothetical issues.  I'm talking about specific
issues with this specific example, that supposedly has already done
all the testing necessary...

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Michał Górny-5
In reply to this post by Alon Bar-Lev-2
On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote:

> On Fri, Sep 14, 2018 at 8:33 PM Michał Górny <[hidden email]> wrote:
>
> > > 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.
>
> OK, back to personal discussion, unfortunately you question this in
> this principal thread.
>
> Personal response:
> In all my years in Gentoo, I've never thought the maintainer lose his
> judgement of how to maintain a package as long as the he/she provide a
> great service to users.
> I've never thought or read this (and other) paragraph as a strict
> white and black nor the holy bible , but a suggestion of how to
> provide a great service to user with the least overhead to maintainer,
> the best practice, the common case.
> I believe there was no complains from users about these packages, on
> the opposite users report issues and are happy when resolved after
> proper investigation.
> I guess something had changed recently in Gentoo in which QA try to
> take the maintainer judgement try to enforce a black and white
> perspective and without looking at bug history and other sources.
> I believe this is a regression and not a progression, I was very
> disappointed to see this new side of Gentoo in which common sense for
> a specific case cannot be discussed individually, nor that a fixed bug
> is hijacked to discuss a principal issue without opening a separate
> formal QA request to discuss properly, address some of the argument
> raised by fellow developers and the reaction of requesting to ban
> developers without any mature discussion. As you can see this in this
> thread is not black and white.
>
I should point out *once again* that:

a. nobody requested banning developers,

b. Bugzilla access suspension was requested because of your hostility
in closing the bug and not the technical issue in question --
or in other words, to prevent you from closing the bug again.

However, if you continue spreading harmful misinformation about my
intentions in attempt to prove your point in technical matter, then
I believe we have much more serious problem to address here.

--
Best regards,
Michał Górny

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2
In reply to this post by Richard Yao-2
On 09/13/2018 07:36 AM, Richard Yao wrote:

>
>
>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
>>
>>> On 2018-09-12 16:50, Rich Freeman wrote:
>>> There is also the case where we want these warnings to block
>>> installation, because the risk of there being a problem is too great.
>>
>> I really disagree with that. So many devs have already said multiple
>> times in this thread that "-Werror" is only turning existing warnings
>> into fatal errors but "-Werror" itself doesn't add any new checks and
>> more often requires "-O3" to be useful.
> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.
I had a discussion off list about this. My remarks on this were
incorrect. However, I strongly disagree that -O3 is necessary for
diagnostics to be useful.

>> So let's turn this around: Please show us a *real* case within Gentoo
>> where "-Werror" prevented a real problem which wouldn't otherwise being
>> noticed. E.g. show us a package which was merged on user's system,
>> replacing a working previous version of that package causing *real*
>> problems which could have been prevented if package would have set
>> "-Werror".
>>
>> Unless you can do that we don't really need to discuss this. Simply
>> because everyone interested in "-Werror" *can* set that flag via CFLAGS,
>> even just per package, whereas the majority, not interested in this,
>> cannot do the same to filter "-Werror". Nobody advocating for "-Werror"
>> replied to that fact yet.
>>
>>
>> --
>> Regards,
>> Thomas Deutschmann / Gentoo Linux Developer
>> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
>>
>
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Alon Bar-Lev-2
In reply to this post by Michał Górny-5
On Fri, Sep 14, 2018 at 8:53 PM Michał Górny <[hidden email]> wrote:

>
> On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote:
> > On Fri, Sep 14, 2018 at 8:33 PM Michał Górny <[hidden email]> wrote:
> >
> > > > 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.
> >
> > OK, back to personal discussion, unfortunately you question this in
> > this principal thread.
> >
> > Personal response:
> > In all my years in Gentoo, I've never thought the maintainer lose his
> > judgement of how to maintain a package as long as the he/she provide a
> > great service to users.
> > I've never thought or read this (and other) paragraph as a strict
> > white and black nor the holy bible , but a suggestion of how to
> > provide a great service to user with the least overhead to maintainer,
> > the best practice, the common case.
> > I believe there was no complains from users about these packages, on
> > the opposite users report issues and are happy when resolved after
> > proper investigation.
> > I guess something had changed recently in Gentoo in which QA try to
> > take the maintainer judgement try to enforce a black and white
> > perspective and without looking at bug history and other sources.
> > I believe this is a regression and not a progression, I was very
> > disappointed to see this new side of Gentoo in which common sense for
> > a specific case cannot be discussed individually, nor that a fixed bug
> > is hijacked to discuss a principal issue without opening a separate
> > formal QA request to discuss properly, address some of the argument
> > raised by fellow developers and the reaction of requesting to ban
> > developers without any mature discussion. As you can see this in this
> > thread is not black and white.
> >
>
> I should point out *once again* that:
>
> a. nobody requested banning developers,
>
> b. Bugzilla access suspension was requested because of your hostility
> in closing the bug and not the technical issue in question --
> or in other words, to prevent you from closing the bug again.
>
> However, if you continue spreading harmful misinformation about my
> intentions in attempt to prove your point in technical matter, then
> I believe we have much more serious problem to address here.

Unfortunately you still continue the personal discussion in principal
thread. I will not cooperate with that as it missing the point. Throw
the entire process you are trying to enforce your view and your
interpretation of the process as if enforcing that may have benefit.
Your request to ban via bugzilla access was rejected with explanation.
The bug that was closed was fixed, if you wanted to have a principal
discussion you should had opened a different principal one and discuss
the issue in opened mind, reaching to a conclusion that we need to
escalate the discussion together. I beg you as I beg you in bugzilla,
please do not turn this thread to personal one, it is not productive.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Michael Orlitzky
In reply to this post by Rich Freeman
On 09/14/2018 01:52 PM, Rich Freeman wrote:
>
> Wouldn't the flip side of this be demonstrating that this has actually
> caused issues?  If following upstream discovers no bugs and also
> causes no issues, why not leave it to maintainer discretion?
>

We know it causes issues, there are hundreds of bugs about it (bugzilla
stops counting at 500 on a search for "Werror").

No one has answered the question: what do you do when a stable package
breaks because of a new warning?

If there's no answer to that question that doesn't involve making an
unofficial in-place downstream-only edit to a piece of code that is (by
the opposing argument) intensely security-critical in a stable package,
then we're all wasting our time talking about this.

123456