From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-85953-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 3AFBB138334
for <garchives@archives.gentoo.org>; Fri, 14 Sep 2018 17:52:39 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id DF132E09BB;
Fri, 14 Sep 2018 17:52:34 +0000 (UTC)
Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193])
(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 87311E0990
for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 17:52:34 +0000 (UTC)
Received: by mail-pf1-f193.google.com with SMTP id s13-v6so4636944pfi.7
for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 10:52:34 -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:cc:content-transfer-encoding;
bh=UByuvgBddQIoTsV/eaqWd/KtBoFKIukBKqxsenm/ZiA=;
b=Ry7Rzcn0FsPrN1BSDRXOHR1kPlFioi2YhzcuRBzQe6r+mYmSNgTjg4iEHTXeceqcKS
tqs+byqoJkw8l92oDM+a6TAVX/DUpTphlXyw2e/OPtHC+eJbCGs7A4Z2Tkq6vKj1deB3
XvM0UUEDQKHLytytZpENGV8eV0M4mYBj9oPQ74OQ74BIdvEb3lzIBQOkBuLNvenQs/lW
xljlxPYwNjrBEkmy5wDKNLCpdF9Gbgy/ImZQhxImkHdNvXRoYsDBLXTZJliCQLLKyVoS
ToOnqK2meoBt8h3mTeShRLdua08zbrZFHLin1GyJlNk3JOQTkfwDShGZOI6A8a7XnK7p
jaVw==
X-Gm-Message-State: APzg51ByQ5AxezaA4eGDrVaGbwIisyd617CZX/7zMy5czvJ3aB+9d1Ss
lQb7eLrWTdOfKwIoOhQ14zpWIZUuAia/UEPXLaDEeA==
X-Google-Smtp-Source: ANB0VdaQhHZDSkFaXENLnEuX/cRH5H/A/mKpPjYqzVcCT0qw+6MgUWf4C4hE4HO4VaHWLya7jAzAMA5CfS7EyIZRyPk=
X-Received: by 2002:a65:4b88:: with SMTP id t8-v6mr12982742pgq.239.1536947553029;
Fri, 14 Sep 2018 10:52:33 -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> <CAOazyz21ZoeWJXZmx65V-uKZvT7XCEzcd9UtrDdxEyNGkDBzsA@mail.gmail.com>
<4318377f-9428-d79a-3ba3-5b2c1ad68166@gentoo.org> <CAOazyz03wKGqF1d65XcxG9JC2dDQHUhzj_eS4XqL7DVSJa5hLQ@mail.gmail.com>
<1536946390.1087.1.camel@gentoo.org>
In-Reply-To: <1536946390.1087.1.camel@gentoo.org>
From: Rich Freeman <rich0@gentoo.org>
Date: Fri, 14 Sep 2018 13:52:20 -0400
Message-ID: <CAGfcS_kaHuY9b5CkhQwLzZc0WFSaRrj1uJtu+3F3NkwcLRGLSQ@mail.gmail.com>
Subject: Re: [gentoo-dev] Changing policy about -Werror
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Cc: Richard Yao <ryao@gentoo.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: e52c0032-4303-4508-9717-c260c22009c3
X-Archives-Hash: 41755d5e3dde4f5e14fdd74835c43667
On Fri, Sep 14, 2018 at 1:33 PM Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> =
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...
--=20
Rich