From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 069CE38460B4 for ; Wed, 3 Apr 2024 13:19:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 069CE38460B4 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 069CE38460B4 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::636 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712150398; cv=none; b=LS17k3EujDAA32Lit3Sdgz4ScYYlBNJBcxWtxS10tD8TCfkPQBtgXNCb1X3Kdt/nsU/C+JKKf7pd0boy247nfWqdTiSjxl/bJBVM+VgyhUjh3y666quBGHUXcDg9eQeN+pCNP3Q/pOXDfIexm9rWBOEPyYlrg3SUkA9HyLVTn1s= 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=kXUFerb/eKH/1VJfCHWX8LcbOZC3XJILlDsltKPl6FTkFNzkqSUXPEHoQcCaSpW5aqzqxlN60NtbKsIYeo6V/tI+FP1KYIDF1HMSkNzwJngBJPaAe3ZgiYHcMPqv5VXyO6PBSHN9aHDn+RUDLe3oulDf5zGM/+L9u+xfpV1/vGs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a4e61accceaso511598966b.2 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=gcc.gnu.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=FAY4ZKVQymersZh98puYLf8ExLJLWz9Ya8/crXLZkwf+yXpW/agu6OuewttQfieNv3 GQvPIVfCSNY9enU6uOPJsks3zufv7qoyeM6RQR+RNTqEZBK3WGsd5ZZbU1w2QEAscI/I thVNhe148eYEloHYgcEMSWpz7lqDFKs4C9OPVMWQeUby6WWyJO/Wu5nLoqLnPZxjIWry SR7rq1pD+sYlzlycXLxAH/wIvD8uDvZfBuK4Vl9ZgWqBGgYlbCvnomfr/kuN3HQ+Y3p0 JzUtxys7kvoqeGqjVAFqCvUDiiqWhcWdwC5sGH+sJtThprCDarGpK8A/mwWka+pWsA7G bxOA== 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=DGuSxE24AtdGgQgduZX2rOFMPk8yFJclahFCzvtMZJ+bjpFB7EtVY81+QzafyKhzsj H/WOu/Pfff4b6qHwKgdTomIy+qEyjlq8Td9psy2QHGTOoaoPeXH3l57gGmDrkOX6lKXj HJ1c8cCjjXLycYmuVnyNOinZ1hSIkQLDHL3FGSdO8LvoqMgv38PgJVeGbYMLLP459wsl 1MwBp4BCkGz7ZDm3kZ8knT4F3v/PGMQ1F2P4lM92KaOkgQvYjP8NbTXaLxXPfzhJXdNm Q6u7fYU216keJmhIQqf1aT7wRn3a9UCNAM5XAaHENaPvcDLMqiNw5P7kdj9/f3zT8cLw SBhg== X-Forwarded-Encrypted: i=1; AJvYcCWdKVBQKPp0YJ+ouZlpTO1zrAt30S/PbWG0k9Q7ksNiRks5ECPdbn/ycr53cLRY24uSGQzzPdQ8d6BSlVX1gmA= X-Gm-Message-State: AOJu0Yzx8bdl/SGh9shxLt7K2iUmLWLaQx6OPNK9QafvDPAWnSlyu3fy ulNON2D83xKn4KqYzWq/F+XJJENaxigONBrJiLYVN2W9GY26gZKRZ//QjyNbpUdtq8KYA5PZYJm 4higsdzRz4W+Q1gGZPFheLcvps/3zgV0bl9nT8g== 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.0 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