From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id HhjfE1IaDWYBKiEAWB0awg (envelope-from ) for ; Wed, 03 Apr 2024 04:58:58 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=pLm2m4LY; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 363751E0C0; Wed, 3 Apr 2024 04:58:58 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1B3231E08C for ; Wed, 3 Apr 2024 04:58:56 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 111AE384645B for ; Wed, 3 Apr 2024 08:58:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 111AE384645B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1712134735; bh=YZNQUxb0a9JA621sCRrhxwVc0ZFl+K52FrTTlbi+Muw=; h=Date:To:cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=pLm2m4LYzwDmAuo3quC7dQcuyFkPTQipngQJEMAQnhW7W+j3XvXN3GVeVCHsJYrxp S5oqorurd8eDcxOwxbzBmrLIUFIyisA4RffD5GhzLNSQGk1R1vqrkBvo+lvb3Zu36r Vj9XLzxh9dqREn0J+DiVexFgWSa3yb0sU3/BAIJI= Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id 674953847700; Wed, 3 Apr 2024 08:57:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 674953847700 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 674953847700 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712134680; cv=none; b=oqxMH+ODasMd9KiLogg80UBlSuA2G5w0m5HyjjW1eDVHX83lwreDZTiEaOtZZGA+Bk/fHgEJTTPoD1URfRVIG0BI2JOhic33+3+eiQc2fQjeberjQpG6ijj0e4YtJrKcyIXmFIsxUlq4HwijPT28TsavapTnPi2YVsg5Rr+IkH0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712134680; c=relaxed/simple; bh=oZiu5FSRiooBOsarXNelGb4mObhJyiu733Z2KpJp7Iw=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=Aflf86+XP0GQbVKLiP+mW0afjCCBzBHSj7DYg9j4dNw3LhpVYAd6bdxRgrhqbU0wxglPd+mTxBEtO2KqTqE3m+Ji9rS5LqnLV+MkS6hgd11DNw+wXm6qPkQmkVPxNH00sHKnJu4fYe8LXuEkG0TYLEfMMdo3vVfrAt/3URS6uyQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.5.241] (unknown [10.168.5.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 6052E5CA3D; Wed, 3 Apr 2024 08:57:57 +0000 (UTC) Date: Wed, 3 Apr 2024 10:57:57 +0200 (CEST) To: Jan Beulich cc: Jakub Jelinek , Christophe Lyon , binutils@sourceware.org, GCC Mailing List , gdb@sourceware.org, Nick Clifton , Joel Brobecker , Carlos O'Donell , Maxim Kuvyrkov , Thiago Bauermann , Adhemerval Zanella Subject: Re: Patches submission policy change In-Reply-To: Message-ID: <9o7ss477-q221-on04-4sor-151q11s7s99n@fhfr.qr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spamd-Result: default: False [-3.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_SHORT(-0.20)[-0.987]; MIME_GOOD(-0.10)[text/plain]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWELVE(0.00)[12]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DBL_BLOCKED_OPENRESOLVER(0.00)[configure.ac:url,gnu.org:url] X-Spam-Score: -3.30 X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Richard Biener via Gdb Reply-To: Richard Biener Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Wed, 3 Apr 2024, Jan Beulich wrote: > On 03.04.2024 10:45, Jakub Jelinek wrote: > > On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > >> Any concerns/objections? > > > > I'm all for it, in fact I've been sending it like that myself for years > > even when the policy said not to. In most cases, the diff for the > > regenerated files is very small and it helps even in patch review to > > actually check if the configure.ac/m4 etc. changes result just in the > > expected changes and not some unrelated ones (e.g. caused by user using > > wrong version of autoconf/automake etc.). > > There can be exceptions, e.g. when in GCC we update from a new version > > of Unicode, the regenerated ucnid.h diff can be large and > > uname2c.h can be huge, such that it can trigger the mailing list size > > limits even when the patch is compressed, see e.g. > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636427.html > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636426.html > > But I think most configure or Makefile changes should be pretty small, > > usual changes shouldn't rewrite everything in those files. > > Which may then call for a policy saying "include generate script diff-s, > but don't include generated data file ones"? At least on the binutils > side, dealing (for CI) with what e.g. opcodes/*-gen produce ought to be > possible by having something along the lines of "maintainer mode light". I'd say we should send generated files when it fits the mailing list limits (and possibly simply lift those limits?). As a last resort do a series splitting the re-generation out (but I guess this would confuse the CI as well and of course for the push you want to squash again). Richard. > Jan >