From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id F398B3846411 for ; Wed, 3 Apr 2024 13:19:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F398B3846411 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F398B3846411 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::62f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712150398; cv=none; b=pLnGmbta4VVVuN91RcqnsbP0dryexCVzXlw/9esVYjKIbQv7oo0SPrV8zqgtYvkzVS+XOP2TqZ6Gw057GOTZmzYW4ZKVv2qxM4Qfcxn3GnLYGMWfo56bo7PxQCzMcBtcMoNf4QDJk7LN1VDMrKoMg80WYlFANYRLTCA6AfCSLFo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712150398; c=relaxed/simple; bh=kbiZ1qgFgKMU7QRGp3BgrTg4uYheFitSpkPAap+Pgb8=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=KukyUDKt5apB8dNwE5XyWdAoVslpcm4lc6VTVLBwWQuuhbxAXWsfuIA21aobm/qspxcKi+hCGyUBUIFKam9DSEtvmvc+OAjkor/oVJoEdMtI89Nl2RFtKmBTfn6EOJQinEPxQY7Fg8+e5YO8sjwjqggm+uxVq9Pb2x5FyOxuedk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a4715991c32so828041766b.1 for ; Wed, 03 Apr 2024 06:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712150394; x=1712755194; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=l+junaBnskWDMYRrHKDs1wTC6uUrybiihsL13wJn2Uc=; b=bnCJd94sPZllJMVseXYfLwlQnqKjLjawOKxaQg7QNG6hxWOnlxo1itnn/fRlks0Sf/ Boc6GXwLBsOjzMsrO17k9m5Nvm+Uck/NqehhOm1MfSUczyUV6E6MCJ4Vtv4NyJIqxMRw hNVrpTSrOsOmnBV370bYuYTlZB/r8XU2zQFIqIida8mAEgTAHuAGQY5III4ClBgaAdZn kNZzQX3v/KcNIT5h3vNPAZ2Jaci7QdEgEV+/WC/UOlhsr3S9LLlcDYrSRgV8dblFmSIp miJnD+cYBbXuiydT1gO9EG4Z4G1cwljrrDrY7u+AAwGnoamE+mWTUdNgXiovA2zNFjJm qlpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712150394; x=1712755194; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=l+junaBnskWDMYRrHKDs1wTC6uUrybiihsL13wJn2Uc=; b=XwaNGBJX96kbQUMac5qlctDEK+Bsiko+su13yU/mRuzlFWaLTOaqriE1fUiL1RInj7 6hdQDDKfqVoxOHKdYBZ6xlggUgnyBt1yCUGWKrBk0LTEGjfLQfNQtxmqE2x+YcvAsrsV kN8BhPEstm60K8frN38UhRXzvwHkBMugLnEPTTdgKN5rIezUqgTtWhJPApMqg8or0fuV GrXKr6EGG9HgkYJqfCKU/uaDkIElF1BaJc68Uos5gNNEXllwgrT3rQG0yxCi8ECy5MIC UneMc7+zRo6EjJ+2nVktTqDB/ma5O+T5aTjj+UbMy+++I/mKUqhyCikUugBKTwhTwubS kiAQ== X-Forwarded-Encrypted: i=1; AJvYcCUjnp6GDmP/Lo0c0PoTQLIhW4zNKdzBoDIqqiyCXsHTnivAPvZUQ7kqP+OdIIIo4c2rvUPQu0khKCjygbWCwB4ns3U= X-Gm-Message-State: AOJu0YyVaL6zRfOt4hgbHxbgSqfAXPpVFg7xD/ntzzaObY9m++cNKi38 xUSxjv4iAck/qDac6Pjo2Mu2KvQqouv5xDARh689oKhVmVRMl1aXbMrMe2qdg5IdqXHw2xqI43v EJgrq6HC/66dYFQ7fmx4TMyn9hYKEOb1sBnLd1g== X-Google-Smtp-Source: AGHT+IF17pQabZPtazYgIjNh1ym4HpHyvg7XLqVRbnfq//aj1pdmUD3hMxODBSYPAeAuYcfdVbzougnpC1xZCc6MtzU= X-Received: by 2002:a17:906:b151:b0:a46:5d40:eb97 with SMTP id bt17-20020a170906b15100b00a465d40eb97mr8708167ejb.70.1712150394602; Wed, 03 Apr 2024 06:19:54 -0700 (PDT) MIME-Version: 1.0 References: <9o7ss477-q221-on04-4sor-151q11s7s99n@fhfr.qr> <8c4f8e79-67a2-4834-8b8b-d9223716ea89@suse.com> In-Reply-To: <8c4f8e79-67a2-4834-8b8b-d9223716ea89@suse.com> From: Christophe Lyon Date: Wed, 3 Apr 2024 15:19:47 +0200 Message-ID: Subject: Re: Patches submission policy change To: Jan Beulich Cc: Richard Biener , Jakub Jelinek , binutils@sourceware.org, GCC Mailing List , gdb@sourceware.org, Nick Clifton , Joel Brobecker , "Carlos O'Donell" , Maxim Kuvyrkov , Thiago Bauermann , Adhemerval Zanella Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,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 List-Id: On Wed, 3 Apr 2024 at 12:21, Jan Beulich wrote: > > On 03.04.2024 10:57, Richard Biener wrote: > > 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?). > > Well, that would allow patches making it through, but it would still > severely increase overall size. I'm afraid more people than not also > fail to cut down reply context, so we'd further see (needlessly) huge > replies to patches as well. > > Additionally - how does one up front determine "fits the mailing list > limits"? My mail UI (Thunderbird) doesn't show me the size of a message > until I've actually sent it. > > > 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). > > Yeah, unless the CI would only ever test full series, this wouldn't help. > It's also imo even more cumbersome than simply stripping the generated > file parts from emails. > Our CI starts by testing the full series, then iterates by dropping the top-most patches one by one, to make sure no patch breaks something that is fixed in a later patch. This is meant to be additional information for patch reviewers, if they use patchwork to assist them. Other CIs may behave differently though. Thanks, Christophe > Jan