Re: Patches submission policy change

[Christophe Lyon <christophe.lyon@linaro.org>]

On Wed, 3 Apr 2024 at 14:59, Joel Sherrill <joel@rtems.org> wrote:
>
> 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.
>

For binutils/gcc/gdb we still have to use specific versions which are
generally not the distro's ones.
So indeed, the number of people having to update autotools-related
files is relatively small, but there are other files which are
regenerated during the build process when maintainer-mode is enabled
(for instance parts of the gcc documentation, or opcodes tables in
binutils, and these are modified by more people.

Thanks,

Christophe

> --joel
>
> On Wed, Apr 3, 2024 at 5:22 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.
>>
>> Jan