From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-85945-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id 99F65138334
for <garchives@archives.gentoo.org>; Fri, 14 Sep 2018 16:40:31 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id F372FE0AD8;
Fri, 14 Sep 2018 16:40:27 +0000 (UTC)
Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id B1F6DE0ACE
for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 16:40:27 +0000 (UTC)
Received: by mail-ot1-f66.google.com with SMTP id a19-v6so5180753otl.12
for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 09:40:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-transfer-encoding;
bh=7cqaDy46QhLiTzqXJlEN1107kkTykCx3bFVpZI9XyII=;
b=JH7mfF9bdHZ70vn7/eSsORJN7+2cO9O51QOKFr4hisx7pRB4T2kFVY6PVYY7Zq18Ds
a4AZ8a3KRTPbE/Hj5gOEj/knCWNw+RYzwAvaVaD9FPEPi0Cn1O5nNKBaXNcI/bkenATz
wsj7AIOJOsMkkJhrwXubBwiFcEwwb+aIVQBrqiSBmtK7AMAd9hzYnZkVG3W9i8z8Wvmo
IX8Jk6DF4Cjeo4o1ocX3ZkmPjYZj19hvjgKnvoYcz6f/+M/tixhLt3OuY0xgSalphb5G
Ddbps7o4KmSGkHNpP9JI9XlUZeX+9lCgUsjcM386PDPGNRLHwb/W1KI2rLsPtBL/dhxU
NZpQ==
X-Gm-Message-State: APzg51DpbH3VJcAxH3IAuHVa7bBvZnv2hkvGbSpbzsFcvj0WX759BLNM
fmkdbipNSC3NQeBEQWi8CNBDuBkKjEiAnVgD8YknS6b5
X-Google-Smtp-Source: ANB0VdYZqoLy7eTDIKc699WXFn+DFmc0XaRGxkIu1n7PtpzhslI/RUtd+CXm39iGknm7jSgMSLcswEtItIRG02ilQbs=
X-Received: by 2002:a9d:29e7:: with SMTP id g36-v6mr5252978otd.369.1536943226359;
Fri, 14 Sep 2018 09:40:26 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
References: <20180909143221.21d784d02f51623e8c57c545@gentoo.org>
<3585947.ej1ZtV7eBo@porto> <CAOazyz1W0i10R=BTZhpR+ss3n8rrxPPVyEMnrdeKdJ6VLaxT5Q@mail.gmail.com>
<20180913223451.03b7d65e@sf>
In-Reply-To: <20180913223451.03b7d65e@sf>
From: Alon Bar-Lev <alonbl@gentoo.org>
Date: Fri, 14 Sep 2018 19:40:13 +0300
Message-ID: <CAOazyz21ZoeWJXZmx65V-uKZvT7XCEzcd9UtrDdxEyNGkDBzsA@mail.gmail.com>
Subject: Re: [gentoo-dev] Changing policy about -Werror
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: f91acef7-1e7a-4b8a-b2bc-385d4add4a6f
X-Archives-Hash: 21ddc4b2febdf97abc225eda625d9a90
On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@gentoo.org> wro=
te:
>
> On Tue, 11 Sep 2018 12:44:38 +0300
> Alon Bar-Lev <alonbl@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. 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 sta=
tus.
Preferably this may be done by automation, I appreciate the work of
Toralf F=C3=B6rster 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=3D list.
>
> Explicit -Werror=3D 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=3Dclang CFLAGS=3D"-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