From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by sourceware.org (Postfix) with ESMTPS id 048033858401 for ; Wed, 3 Apr 2024 12:59:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 048033858401 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 048033858401 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.174 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712149144; cv=none; b=MpslMutoVxM0f+SjBp9kqlnj/x9keyHnNffaOkjVH+JisQlICR27e7UTzhA7QCZM2ulv65AfBpQHjb/jKxwHWwLzbFuRna/4K44xJ/hyI5I/C4ji35Uc5D4QhY0rDY7mOxoO98lZLYEi8ZK7HR15cwq/2EDn0lyo0ffr4j21Suo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712149144; c=relaxed/simple; bh=vy0eOpdsqA7oSOPvBP5Qfwvh4JpHuG5XD9lkrQj4Rjc=; h=MIME-Version:From:Date:Message-ID:Subject:To; b=WBo12UkAdl4yVjGwkR9DFuRNi6g7Z/STViBSZPa2uD9MtgaUKxd1j2iV+tuiBIYB0QXAgtatheLhvC/i97WnN6aAk0GHdc33BtXvqtVze/8n9ynHyuwhWwmdoBi3K9YHJBPY4K1xf5Ui/vgNy6AwRJDQeEbP0aH3yPsVtw244yk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-60a104601dcso65082867b3.2 for ; Wed, 03 Apr 2024 05:59:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712149141; x=1712753941; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cDCqfed4540a/5r+ARKdywMEXRgeZxZQpjSk4pkbOwA=; b=Pp2IQRPs33Ekx3FIakLA6rRRcGV29HJsYbEHrfHFjv2uMkNsTioTe3uAZP2BXkRexI i+rJIfOLVjcRm6vOCigjx71+zNDlQ2cWaT9FXt6hUxnsmfq9xYTzXQlGCDwTnFxQSpj8 DQ8AS4I6LJ0M7vIlcKLr3hc0cO7fmzV+FeWye83AbuD97p6DpIonB2kjZZtySKiYp9OP VicOSfeM+xn9BcfP44HCjjfOPwyAAwLW2zsTk5ebYX2mV4MGCFcXfGHPafoVnXPffOeC eUCRZMH31lHztjyQm2qjxKDQDE3XoyZU064qJQVQZzAnNmoEDZAJnW0s6hX+wEKjvTKt ec9A== X-Forwarded-Encrypted: i=1; AJvYcCVPBgGVokI3tdcrf3d0LnitHAJqkjWYbDr73mjO5FKsl/jBhM62y6IvBB17Z2DiQjAMkfbNqTUe7rSjFPcoxp8= X-Gm-Message-State: AOJu0Yzk7kK59ZCMqwmNehw6XnNrZUlnlY32u+8U81EO9mkHFzpBqwvn 2cXvcoUCjd10peUqoSjPHpSmfE2UBRqBLf+vfToUfz1maNdJGmffQLo2xlUg X-Google-Smtp-Source: AGHT+IHLibmGfaisQkVVlQMLNkF1PoAZWaHWS2XBncFDt4rt8piszaep2AwP0mBj5seuMKon0lH0nQ== X-Received: by 2002:a0d:df91:0:b0:615:ecc:91c0 with SMTP id i139-20020a0ddf91000000b006150ecc91c0mr6236429ywe.20.1712149140908; Wed, 03 Apr 2024 05:59:00 -0700 (PDT) Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com. [209.85.128.172]) by smtp.gmail.com with ESMTPSA id t21-20020a818315000000b006152cd281fasm790371ywf.23.2024.04.03.05.59.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Apr 2024 05:59:00 -0700 (PDT) Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-6150670d372so23034607b3.1 for ; Wed, 03 Apr 2024 05:59:00 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUu4xCbOLmloZ6Pbmd/VeujTwd0v1cnnVIeI+9131hhaEdkmJ/SECh4OqyHDnnLAQSXzC/mWq77UPQmDdAe9hM= X-Received: by 2002:a05:6902:18e:b0:dcd:6a02:c111 with SMTP id t14-20020a056902018e00b00dcd6a02c111mr13034090ybh.11.1712149140279; Wed, 03 Apr 2024 05:59:00 -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> Reply-To: joel@rtems.org From: Joel Sherrill Date: Wed, 3 Apr 2024 07:58:48 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Patches submission policy change To: Jan Beulich Cc: Richard Biener , 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 Content-Type: multipart/alternative; boundary="0000000000004f2278061530c9d5" X-Spam-Status: No, score=-3031.4 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000004f2278061530c9d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another possible issue which may be better now than in years past is that the versions of autoconf/automake required often had to be installed by hand. I think newlib has gotten better but before the rework on its Makefile/configure, I had a special install of autotools which precisely matched what it required. And that led to very few people being able to successfully regenerate. Is that avoidable? OTOH the set of people touching these files may be small enough that pain isn't an issue. --joel On Wed, Apr 3, 2024 at 5:22=E2=80=AFAM Jan Beulich via Gcc 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 yea= rs > >>> 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 usi= ng > >>> 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. > > Jan > --0000000000004f2278061530c9d5--