From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 0D6AD138334 for ; Fri, 14 Sep 2018 17:22:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 42893E0B93; Fri, 14 Sep 2018 17:22:25 +0000 (UTC) Received: from mail-oi0-f68.google.com (mail-oi0-f68.google.com [209.85.218.68]) (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 EEDA2E0B5D for ; Fri, 14 Sep 2018 17:22:24 +0000 (UTC) Received: by mail-oi0-f68.google.com with SMTP id 13-v6so13553664ois.1 for ; Fri, 14 Sep 2018 10:22:24 -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; bh=LXW4wNmjOuZeRiipFR74ItCUSv0CFGd33G0415BI+Zo=; b=ssel5gfI1GxmRXW1Pdunhxry40IkBf1cnnGc8U2zZawMu3Hp1muFvO+6jvJL7CwSAq cJ98feImtMj7n5gXxzTaXgpJb0UornRyAP1tQ5VlW77Oybz4yKesg2qmXxiI2mRAD2wi JbDl0D1e8sMRyQ96hGJUMq8a4XzUV6Dcu0AO+KIpEr5K81UBKCI/GfoDzOzgJEPR8IBR My63hZwi+hedsOvEAOPec5iu7gvYF93P96wjj4v1H/WQzdq/9PbALHwOEOLNZfoEVyxi 5Eue0wsKQYaqQsFMfBaurbMpXWCD/CXNl/pDwrCoIC7BmZQ9yX6be2nMzIFWrLEXFWKB T4gA== X-Gm-Message-State: APzg51ATpEUQ7TwbUGJIJaZa+wz4gk7T++YYeq4RdjF/GaqxNe0mZ0CB X2MOpD1LPFkBTn2IGZx0pdFF8D4A64s7uAT1wnsPhQ== X-Google-Smtp-Source: ANB0VdY43k1TO5bYPqPB2CVHlvn/+S4m7H9hkspVZ+O7PqtM99dkxnOwNikP+YgS0sMjgnZVqV4+7iz3J5DFEbCutZY= X-Received: by 2002:aca:bc54:: with SMTP id m81-v6mr10647124oif.308.1536945744030; Fri, 14 Sep 2018 10:22:24 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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> <20180913223451.03b7d65e@sf> <4318377f-9428-d79a-3ba3-5b2c1ad68166@gentoo.org> In-Reply-To: <4318377f-9428-d79a-3ba3-5b2c1ad68166@gentoo.org> From: Alon Bar-Lev Date: Fri, 14 Sep 2018 20:22:11 +0300 Message-ID: Subject: Re: [gentoo-dev] Changing policy about -Werror To: ryao@gentoo.org Cc: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 2f015b64-5ced-410c-b2e6-40c6dc95dc1f X-Archives-Hash: 3fff558ee52c37adac649a0adf3a2937 On Fri, Sep 14, 2018 at 8:16 PM Richard Yao wrote: > > On 09/14/2018 12:40 PM, Alon Bar-Lev wrote: > > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich wrote: > >> > >> On Tue, 11 Sep 2018 12:44:38 +0300 > >> Alon Bar-Lev 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. > I don't think we should do that unless we provide a USE flag for users > to opt into the behavior. Forcing it on users is problematic for the > reasons others stated. However, letting them opt into the behavior is > reasonable. > > In the case of sys-fs/zfs, enabling -Werror (which includes -Wall) on > USE=debug is following upstream's wishes to build debug builds with -Werror. 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.