From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-85952-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 B15FD138334
for <garchives@archives.gentoo.org>; Fri, 14 Sep 2018 17:48:35 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 411C8E0BEC;
Fri, 14 Sep 2018 17:48:32 +0000 (UTC)
Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42])
(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 EC3B6E0BD2
for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 17:48:31 +0000 (UTC)
Received: by mail-ot1-f42.google.com with SMTP id i12-v6so5385256otl.1
for <gentoo-dev@lists.gentoo.org>; Fri, 14 Sep 2018 10:48:31 -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=vuGoWmiG5F8/PL4OjBpUEbMC7vpM+eYG9fmsbzpmRRM=;
b=XYoq1Rtwi5gzFBYnH4/VxH5CAADBvwvfTUUV22oHMEUwUsNV6abcta91JsxXDM+Kl5
ojJ6JF/kuKBplAFaHej8h9DSCeP8Yo0qPohIca8ahyXBpdqL3Zx0NrQ0NeX5ReNVcBKe
y/RqielXC3nIc/v8CBqg+ssH1xnAW7/wbHx3ixwojmQkmQhYE54r8qWVFU8et/T82hZ1
cuSxkr/hOIEIHFHfYEJsV8bv96HXpEieMp56i24Wp1pv6FXXb0fiD2v10vVzWA4uPyAa
ZGZfAO29GYDuCgzpdzmdNcbqaAdCxQEDjOFO+7rv6JxOl5BaO+X5yWMbfsxMqLmpz0bi
cldg==
X-Gm-Message-State: APzg51B78rfGyeCYKtkaKd1ASAwuskHDgOzk0wt/cx2fLbxm19C0AVqR
F4DECOi6pZlzUsDBfB+fHqi3lkI29ayLwFteXYim3A==
X-Google-Smtp-Source: ANB0VdaxXesb/FG/SBGM9Gt1Zek7qOGvEar7mpC0iuzzXWAUaanZ3zduYw8GB/nCZ1hvPLptIJ/NTOD9PlrBXJLQZ1U=
X-Received: by 2002:a9d:3ea3:: with SMTP id b32-v6mr4870325otc.208.1536947310822;
Fri, 14 Sep 2018 10:48:30 -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: Alon Bar-Lev <alonbl@gentoo.org>
Date: Fri, 14 Sep 2018 20:48:18 +0300
Message-ID: <CAOazyz0dkjt=ioLJ53HwB-SuMpvRdEw1aNtJf+axg2MCbsN7dw@mail.gmail.com>
Subject: Re: [gentoo-dev] Changing policy about -Werror
To: gentoo-dev@lists.gentoo.org
Cc: ryao@gentoo.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: fb8ec5c0-f8b3-4efe-bf19-993aca97e716
X-Archives-Hash: a878dec9544f0f674456ccccf23b0eb3
On Fri, Sep 14, 2018 at 8:33 PM Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> =
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?
>
> Because so far this discussion is not much different than "let's make
> the ebuild fail for some values of ${RANDOM}, and add extra values when
> users complain". Though the variant with random has probably a greater
> chance of failing when *actual* security issues happen.
OK, back to personal discussion, unfortunately you question this in
this principal thread.
Personal response:
In all my years in Gentoo, I've never thought the maintainer lose his
judgement of how to maintain a package as long as the he/she provide a
great service to users.
I've never thought or read this (and other) paragraph as a strict
white and black nor the holy bible , but a suggestion of how to
provide a great service to user with the least overhead to maintainer,
the best practice, the common case.
I believe there was no complains from users about these packages, on
the opposite users report issues and are happy when resolved after
proper investigation.
I guess something had changed recently in Gentoo in which QA try to
take the maintainer judgement try to enforce a black and white
perspective and without looking at bug history and other sources.
I believe this is a regression and not a progression, I was very
disappointed to see this new side of Gentoo in which common sense for
a specific case cannot be discussed individually, nor that a fixed bug
is hijacked to discuss a principal issue without opening a separate
formal QA request to discuss properly, address some of the argument
raised by fellow developers and the reaction of requesting to ban
developers without any mature discussion. As you can see this in this
thread is not black and white.