From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 50D99384772F for ; Wed, 3 Apr 2024 08:45:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 50D99384772F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 50D99384772F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712133919; cv=none; b=tGlAMVx69w9+o80I9EVVDTA5op1vs2tD5OIQA7jIarPv2XSx8poyR8wUqvB9Y5IYlVL+2Y95P+ZhwMYUZQEE/rdxeRlV1IVUJtezrQhx2y8VYAAJF3+A5r8d8hGuPlFp1WQVyNg1ihdZW2UAexqkpUoJeNybv2nK1dYFZZwiVZo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712133919; c=relaxed/simple; bh=AsBJz1BCeyble4XXvfBKCQ+NyZWlllG/D5WOSJiA5cw=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=nTTu5hfxBfQFsbFXiiyounW/AFxPdYXN1fkZ63vXIzL97rWABHcswYl9Z6+TeL/Bd3/NTrWu0XQgAMKxTcCR4xk+QvMxwl43ctqadFV4hrF/+a9wroH2r6umuKit8zLnxG+SdE5U7c5fbMeNP3dpYoJtdF/OTCFZh2pX8c6dFCg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712133916; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=H18MaAnaIGF20ywza2aBZoVerrt3iT8vtpZ+NUkNAAM=; b=GTI7L1NR+dej078amdXVj6ySnkNMyDjuOZDTR1TNb3tDiByPSRiS1fpFl0a8e6mMK67aJA iio+Q8a7UHcSkUlgZ5XgMPpI4aTCP5NiU3EdQdiatEFIEtrJcJUB2Snrcal09bCfewfFRk kHKp2UJb2jL/EDSeXz2EKJemMOBkTyM= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-390-1cp5RmqqMii0e6pRVHBv5A-1; Wed, 03 Apr 2024 04:45:11 -0400 X-MC-Unique: 1cp5RmqqMii0e6pRVHBv5A-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 027912825BB2; Wed, 3 Apr 2024 08:45:11 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7DC618173; Wed, 3 Apr 2024 08:45:10 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4338j4KR1845380 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 3 Apr 2024 10:45:04 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4338j4AX1845379; Wed, 3 Apr 2024 10:45:04 +0200 Date: Wed, 3 Apr 2024 10:45:04 +0200 From: Jakub Jelinek To: Christophe Lyon Cc: binutils@sourceware.org, GCC Mailing List , gdb@sourceware.org, Nick Clifton , Richard Biener , Joel Brobecker , "Carlos O'Donell" , Maxim Kuvyrkov , Thiago Bauermann , Adhemerval Zanella Subject: Re: Patches submission policy change Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. Jakub