From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-85964-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 47223138334
for <garchives@archives.gentoo.org>; Fri, 14 Sep 2018 21:07:32 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 975BEE0950;
Fri, 14 Sep 2018 21:07:27 +0000 (UTC)
Received: from mail-oi0-f65.google.com (mail-oi0-f65.google.com [209.85.218.65])
(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 4420FE0909
for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 21:07:27 +0000 (UTC)
Received: by mail-oi0-f65.google.com with SMTP id b15-v6so14023113oib.10
for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 14:07: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=JHfip3WAIptJYYZIXtOe+prsLV0IA0KJwuH7WiD7+lA=;
b=MIhNZxzuAfAqYbNe+aQZ9b5+KMe3jQsYi+uzj0KmusSXKfNw3SoCLjnbTPlk9RhDFC
5573axIHhZ73zIkeHl+GoiNLCimMZso91N6gXt5JmA7mkpGFwcNuykx2KAxFMr1fgukp
zat7D0gADnv4iqlrrGTYvfTujnBv2niK/Rvp4rvbBpO/pamiRWzPfgX5LfR2tnbiry/+
dXf03CI0kMYPjLscLQ3dmNCI7z36R2O0F3upml+0qRoIGht+aPyTCUYefyQOBCQljvU9
1lIiVTJW6dl7r59YC8IsorwIp9iCeei2qinmrbluYhaisRMwwxbPVd0LgzmRSRd5d3Xq
JEuw==
X-Gm-Message-State: APzg51DwtWSetXgYf/SPicOWuD2vOWq0ZTlcKniQanD9PNVVs0a3+3Ux
MxrYCFyyLmlda+y69itwrx7A4EZlwf184LK353SneQ==
X-Google-Smtp-Source: ANB0VdZosIhln/54ABa2bdoRhICtXs3MySO+3phDM+h5akXiegrySoVESFxMQ45beKCNj7HVUcJfxiPW+3Nkidzxnug=
X-Received: by 2002:aca:ec0d:: with SMTP id k13-v6mr11279721oih.236.1536959245929;
Fri, 14 Sep 2018 14:07:25 -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: <20180913223451.03b7d65e@sf> <CAOazyz21ZoeWJXZmx65V-uKZvT7XCEzcd9UtrDdxEyNGkDBzsA@mail.gmail.com>
<4318377f-9428-d79a-3ba3-5b2c1ad68166@gentoo.org> <CAOazyz03wKGqF1d65XcxG9JC2dDQHUhzj_eS4XqL7DVSJa5hLQ@mail.gmail.com>
<1536946390.1087.1.camel@gentoo.org> <CAGfcS_kaHuY9b5CkhQwLzZc0WFSaRrj1uJtu+3F3NkwcLRGLSQ@mail.gmail.com>
<72caf534-9d11-b88c-5f94-901140a240a4@gentoo.org> <73BDD985-3347-4BA9-967A-7EF75785DA08@gentoo.org>
<c7e6a56e-ceec-034b-5ee5-fcb1fb8d528a@gentoo.org> <CAGfcS_nHjb2St4SscyW_QENn3DtVDek1EM5+-ycKAVJ3eFOzwQ@mail.gmail.com>
<20180914210205.GF26329@gentoo.org>
In-Reply-To: <20180914210205.GF26329@gentoo.org>
From: Alon Bar-Lev <alonbl@gentoo.org>
Date: Sat, 15 Sep 2018 00:07:12 +0300
Message-ID: <CAOazyz1rAJ3u8ziP23TBZxrOCRjZDtx3NqRjnQmOh2YDL5ezBA@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: 20870a03-97aa-4032-bd24-e9ff65b52a57
X-Archives-Hash: 08e1116c152ee4298fde77c07330d300
On Sat, Sep 15, 2018 at 12:02 AM Fabian Groffen <grobian@gentoo.org> wrote:
>
> On 14-09-2018 16:29:43 -0400, Rich Freeman wrote:
> > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky <mjo@gentoo.org> wrote=
:
> > >
> > > On 09/14/2018 03:58 PM, Richard Yao wrote:
> > > >>
> > > >> No one has answered the question: what do you do when a stable pac=
kage
> > > >> breaks because of a new warning?
> > > >>
> > > >> ...>
> > > > Wouldn=E2=80=99t this be largely covered as part of GCC stabilizati=
on? We could reserve the right to kill -Werror in a package where it blocks=
GCC stabilization if the maintainer does not handle it in a timely manner.
> > > >>
> > >
> > > They would be uncovered during GCC stabilization, but then you're rig=
ht
> > > back in the original situation: how do you fix the stable package? Th=
e
> > > only answer that doesn't violate some other policy is to patch it in =
a
> > > new revision and wait for it to stabilize again.
> > >
> > > Other questions arise: Do we block stabilization of clang et al.?
> > >
> >
> > Presumably we could make it a blocker, so then portage won't install
> > the new stable toolchain. That buys time and only affects users of
> > that particular package. But, as I pointed out before you can do that
> > without using -Werror - just block installation with an unqualified
> > toolchain.
> >
> > You would only use an approach like this for packages where QA was
> > fairly important, so the inconvenience would be worth it.
>
> Perhaps, if one persists on going this route, only do this for platforms
> that upstream supports, such that arches which will suffer from this
> (typically ppc, sparc, ...) don't have to be blocked by this.
Exactly in these cases the -Werror is useful as if upstream expects no
warnings then any warning should block installation and trigger bug
report. In Gentoo in many cases we use packages on platform has no
access to, our feedback to upstream is valuable. A great example is
gnutls in which we collectively (maintainer, unstable users,
architecture teams, stable users) found issues on architectures that
almost nobody other than Gentoo has access to.