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 801A0138334 for ; Fri, 14 Sep 2018 20:15:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02A69E0A6A; Fri, 14 Sep 2018 20:15:44 +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 B13B1E0A5D for ; Fri, 14 Sep 2018 20:15:43 +0000 (UTC) Received: by mail-oi0-f65.google.com with SMTP id y207-v6so13888713oie.13 for ; Fri, 14 Sep 2018 13:15:43 -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=/5oPlR3jUIGYB6g4v6WHeCbjv/ghcBll1a6VyShnpFI=; b=f4gI/Ho2h2stpLbX/25nJbArkIdVWA9yaEeFpDXbWeMFEDK2A7DuiGoQCPyJQWkbmy 4T+Sgwkk5aRKdhdEafwD5YdGz7IRxBKXFUDfBp9TtyJbcbVJ9uEB4e/ihZc0X2r//t/0 RRG7q7BRIUwlQftKekREGVmu8uT5ZAIj5BuwELGhwxOdrw95YfcJ9f8kYXITmiyUUUWC pnyu0AmKxs4pgXLM987BdGv6LXO3w+9igkUfgrN3c2Rz7l9YlgZMDTSqqMcSiecGr2E8 j4v150OAw3qMNRgVxzII49mioKcdw/agmUibMFrl9L95CnKA5GPv98cmImR1Qb2W0YoT ETYQ== X-Gm-Message-State: APzg51Bm6q+YqS7YWs/ECBYgyAQT4jB9hh2AO4sy8dCALHo434M1iy0n ZRBmjDfrAq9lO1EoP5aKIuUJw8OpNbs8JpiOCgTT6A== X-Google-Smtp-Source: ANB0VdYyGSRHAKcX/cSayME7uMJkCevWYidGer03jgca8MaCuqbPnY3SsFNSKGL5OUlZCe1MJ/CG7lmlfASBcng5IFA= X-Received: by 2002:aca:ec0d:: with SMTP id k13-v6mr11160601oih.236.1536956142108; Fri, 14 Sep 2018 13:15:42 -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> <20180914205346.3315a5d9@sf> In-Reply-To: <20180914205346.3315a5d9@sf> From: Alon Bar-Lev Date: Fri, 14 Sep 2018 23:15:28 +0300 Message-ID: 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: 3aa76b0a-27a2-4c3d-8b66-4788ab927b08 X-Archives-Hash: c1fedf0686b29ea1fba4a7cae468b1ea On Fri, Sep 14, 2018 at 10:53 PM Sergei Trofimovich wro= te: > > On Fri, 14 Sep 2018 19:40:13 +0300 > Alon Bar-Lev wrote: > > > > > 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= status. > > 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? > > 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 Fix in place if false positive. Revision bump if positive. > - pull new upstream version and fast-track stabilization without > usual soak time in ~arch No reason to wait for upstream if obvious positive just like any bug fix. > - no revbump, apply the patch as-is and hope it does not break > existing users. Correct. > - anything else? Patching the package (stable and unstable) to remove -Werror if too many of them and downstream maintainer reaches to a conclusion that the overhead is too high and benefit is little and provide this feedback to upstream to work together on a new release of upstream which resolves all warnings with newer toolchain. > > > > 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. > > > > 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. But how can you get the report to evaluate if it is real or not? I fail to understand this argument that is repeated over and over. Everyone is smart after the did... while we are looking for the trigger to evaluate. > > > Toolchain just happend to get better at control flow graph > > > analysis. Fix can easily wait for next release and save > > > everyone's time. > > > > 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. Correct. My believe is that it is up to maintainer to decide. > > 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. Yes, but we are not talking about by default, right? > > > 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. > > > > 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. > Any mechanism that is fully supported by upstream and downstream maintainer find it stable should be enabled by default. I do see the benefit of disabling tests not because they may break as per the same argument I would like to have these reported and investigated, but to save resources (time and CPU) which may be significant. Thanks, Alon