From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-85958-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 CEEE3138334 for <garchives@archives.gentoo.org>; Fri, 14 Sep 2018 19:53:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73D0AE0C09; Fri, 14 Sep 2018 19:53:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 06E4DE0AF0 for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 19:53:53 +0000 (UTC) Received: from sf (trofi-1-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id E9405335D0F; Fri, 14 Sep 2018 19:53:50 +0000 (UTC) Date: Fri, 14 Sep 2018 20:53:46 +0100 From: Sergei Trofimovich <slyfox@gentoo.org> To: Alon Bar-Lev <alonbl@gentoo.org> Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Changing policy about -Werror Message-ID: <20180914205346.3315a5d9@sf> In-Reply-To: <CAOazyz21ZoeWJXZmx65V-uKZvT7XCEzcd9UtrDdxEyNGkDBzsA@mail.gmail.com> References: <20180909143221.21d784d02f51623e8c57c545@gentoo.org> <3585947.ej1ZtV7eBo@porto> <CAOazyz1W0i10R=BTZhpR+ss3n8rrxPPVyEMnrdeKdJ6VLaxT5Q@mail.gmail.com> <20180913223451.03b7d65e@sf> <CAOazyz21ZoeWJXZmx65V-uKZvT7XCEzcd9UtrDdxEyNGkDBzsA@mail.gmail.com> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 71b31728-0195-414e-96f0-2c5d6da430c7 X-Archives-Hash: 7891b2b23a3dc7d1cdaa092ff87a7a2a On Fri, 14 Sep 2018 19:40:13 +0300 Alon Bar-Lev <alonbl@gentoo.org> wrote: > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich <slyfox@gentoo.org> w= rote: > > > > 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. =20 >=20 > 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? =20 >=20 > Correct. >=20 > > If you do it then what is your workflow to fix breakages > > appearing in stable packages caused by minor environment > > changes like toolchain tweaks? =20 >=20 > Correct. >=20 > > 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. =20 >=20 > 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 s= tatus. > 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. 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? =20 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. =20 >=20 > 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. =20 >=20 > 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. =20 >=20 > 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. --=20 Sergei