On Wed, Apr 3, 2024 at 6:23 AM Jan Beulich via Gcc <gcc@gcc.gnu.org> 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.
>

Massive patches need special handling either way; I wouldn't lift the
mailing list limits because of this change.

I'm in favor of this change for typical patches.

Jason