Hi,
I was the one that (re)trigger this discussion, I thank bircoph for
opening this up.
First, let me apologize that I did not test the capi USE for long
time, as this option is not used for long time by users, I am also
apologize of treating bug from anyone (may it be user, developer or
even qa) at the same SLA. It took one hour from report to fix
including evaluation of the issue and submitting the fix to upstream.
The package is non-stable for four months and stable in amd64 for a
while without users reporting that because as expected feature is
seldom used. Please avoid flaming me for this and address the
principal subject at hand as it is important.
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.
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 am maintaining selected packages in which upstream is fully aware of
-Werror implications, accepting any patches to resolve issues found by
anyone. My judgment as Gentoo developer for these selected packages is
to absorb additional overhead in maintaining these packages while
helping upstream and users to enjoy higher quality. I've never assumed
that an effort individual project is willing to invest is something
that overrule by any other project as long as users receives a great
service (bugzilla stats are available).
I believe that a maintainer in Gentoo is a special role, we not only
helping users, but we also help upstream to improve their packages. We
are unique as permutations and architectures that are used by Gentoo
users are so diverse that we find issues that nobody else finds. In
addition to these, we also use latest and greatest toolchains, tools
and utilities, this triggers issues at Gentoo even before other
distributions.
Gentoo non-stable users are a great asset as they are willingly
helping to find these issues, with the understanding that their system
may break. A good relationship between Gentoo downstream maintainer
and upstream actually helps to find fixes long before other
distributions are affected. Even when I was in Red Hat, my policy was
Gentoo first, as a package that is built in Gentoo without tweaks will
be built successfully in all distributions (except of Java maven
packages in which we are far behind).
Over the years, many Gentoo developers, I included, have built
relationship with most active upstreams in my slot to push Gentoo
interests into upstream, I invite you to portage tree to see in how
many packages we drag patches from one version to another or to
evaluate ebuild tweaks. This mutual respect also suggests that if
upstream has a -Werror policy, in which every issue as minor as it can
be must be taken care of before package is considered to be usable, I
as downstream maintainer should help and apply the policy to help
upstream to improve its policy.
More and more upstream developers are aware of static code analysis
benefits, they use every source of information possible, opening
coverity to opensource made a great difference, the -Werror is yet
another tool to find unexpected issues. The collective mindset was
progressed greatly since 2009 where flameeyes opened bug#260867. At
least once per 10 years one should re-evaluate his policies, the
industry is changing.
When upstream policy is to have zero warnings policy, suppressed by
explicit suppression (code or compile argument), and when upstream is
friendly and actively following the policy of investigating each
incident and fix it properly, we can help for selected packages.
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, for 30 years
I tell my developers and students that "It compiles" and "It works"
are two different statements. One should only be thankful for any tool
to detect issues hidden within code, stop and re-evaluate when new
issues are found.
Let's take two recent examples from my queue:
bug#665464 in which there was unused return code variable, this made
me look into source code of upstream from master back in time until
code was introduced to find out when return code was used and why it
was removed, reaching to a conclusion that indeed return code should
be ignored and submitting a patch to upstream to validate that,
upstream confirmed and merged. Imagine what would happen if I would
have found that it is a real issue and should be addressed? Both users
and upstream would have benefit from finding and fixing the issue.
bug#664198 in which -Werror found mismatched memcpy, this was an
actual bug that must be fixed.
Based on the above we have in recent month one false
