From: Jakub Jelinek <jakub@redhat.com>
To: Christophe Lyon <christophe.lyon@linaro.org>
Cc: binutils@sourceware.org, GCC Mailing List <gcc@gcc.gnu.org>,
gdb@sourceware.org, Nick Clifton <nickc@redhat.com>,
Richard Biener <rguenther@suse.de>,
Joel Brobecker <brobecker@adacore.com>,
"Carlos O'Donell" <carlos@redhat.com>,
Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
Thiago Bauermann <thiago.bauermann@linaro.org>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>
Subject: Re: Patches submission policy change
Date: Wed, 3 Apr 2024 10:45:04 +0200 [thread overview]
Message-ID: <Zg0XEJ6yt2lLa7MS@tucnak> (raw)
In-Reply-To: <CAPS5khZeWkAD=V8ka9g5eECDNK3BDHFNZJuMpVC+HeDmkVJMCg@mail.gmail.com>
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
next prev parent reply other threads:[~2024-04-03 8:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-03 8:22 Christophe Lyon
2024-04-03 8:30 ` Jan Beulich
2024-04-03 13:11 ` Christophe Lyon
2024-04-04 8:12 ` Jan Beulich
2024-04-05 7:22 ` Christophe Lyon
2024-04-03 8:45 ` Jakub Jelinek [this message]
2024-04-03 8:49 ` Jan Beulich
2024-04-03 8:57 ` Richard Biener
2024-04-03 10:21 ` Jan Beulich
2024-04-03 12:58 ` Joel Sherrill
2024-04-03 13:23 ` Christophe Lyon
2024-04-08 15:37 ` Richard Earnshaw (lists)
2024-04-03 12:59 ` Jason Merrill
2024-04-03 13:19 ` Christophe Lyon
2024-04-03 9:50 ` Jonathan Wakely
2024-04-03 15:03 ` Simon Marchi
2024-04-04 21:35 ` Mark Wielaard
2024-04-04 21:51 ` Simon Marchi
2024-04-05 6:44 ` Marc
2024-04-05 7:17 ` Christophe Lyon
2024-04-06 16:29 ` Mark Wielaard
2024-04-07 12:32 ` Jonathan Wakely
2024-04-07 14:02 ` Mark Wielaard
2024-04-07 14:20 ` Jonathan Wakely
2024-04-07 22:00 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zg0XEJ6yt2lLa7MS@tucnak \
--to=jakub@redhat.com \
--cc=adhemerval.zanella@linaro.org \
--cc=binutils@sourceware.org \
--cc=brobecker@adacore.com \
--cc=carlos@redhat.com \
--cc=christophe.lyon@linaro.org \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sourceware.org \
--cc=maxim.kuvyrkov@linaro.org \
--cc=nickc@redhat.com \
--cc=rguenther@suse.de \
--cc=thiago.bauermann@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).