From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 81E1038460B4 for ; Wed, 3 Apr 2024 13:23:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 81E1038460B4 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 81E1038460B4 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::529 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712150602; cv=none; b=P1+wXyA66WHerInn66pWdeUm/5BotqVfaSGFNJDVujDCb+dtG937/0G0DUO4HFoqVnlB4X2giAo338bpmtJAuB42qqQS8igrDxQ2zEA/3uNi5MX3s3ab9EbJArfYhqLC3kwhJFT8zVEVnMK2GG4MEegn8n8P7vzZj8SeRno75/M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712150602; c=relaxed/simple; bh=kGB5AbwayOJWChuRq5yRWWcmTjQhi43x4F1P/oxy3yo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=JmKWaaQ6ys6s7h9T/WS4fRVNJ8Uuuv1CqU00zU0VrO/0xQ+aLX7JOFovKWWVekdbt8EtVMN+rZDXM0kwyllLLdFFJQnE7A4D3glf9dWg8Ve1rXd1fdFCYIyxFkGxaw6yO0gu9xRxO03YbPJt41OXCgT+1jWiUZGEzz6KzbKuzgU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-56e06116eb4so908458a12.3 for ; Wed, 03 Apr 2024 06:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712150599; x=1712755399; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HKoB4Yv/LG7VjlrwPsKn8XZBjZPQ4oq2OubKLSz1hew=; b=iHeXXUWVLKqltQnpAA8EDQpfpuiVUOXVoIYmU9NMm0NfJ6mTsGVBUYgDowWkejnBqJ JjbgZRgbdNtBuqfbhST9a0h0RONcOuRZP9zVtowS/KH1B19r/HpuFWEOEWHM7Tat2nI9 ptLi+tT/Kyd6sxul/nXXHiJvU/3ZcYdS1oIQmIY/eb4fsDS0R9msbmZzckv/+Evj7iwk dRdPybsnujVgwSOPAY6oeUZvWuVA0URABsD3LJ9sq95xd0oM+qhaHAm5M/Inp590P93x dGVybWMNeCP4qhZ3WS7pUCk9WmGRQFD+oAb0YTDJH8OL8CFX4Zy77nNM8AHrIMwtbuc6 glbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712150599; x=1712755399; h=content-transfer-encoding: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=HKoB4Yv/LG7VjlrwPsKn8XZBjZPQ4oq2OubKLSz1hew=; b=qUfZL8C7/2Hapnz5znrWWk0fnmDz2QlmxJH6zlzoXH+01tgEhAYPjAzKj6MxznMlXo vDUKZ73E0UmxTVNxeQK1YgQUG8cMj4l90RrwDjQxI7TTmQVG+ZVFGbnx21BeK2NH9l00 wbXIWQT3aYG4HrAwdJcPp5JRDh3s5EAooOdRcBTOHxThakb4ePzKeMduBxX+07NCTW8i NPI0tc1pMSZzRxwr0uuZf9+kjy1N7XoWBOSw9xG6IgGKTWiu9de1uAEcQMZuiZibDG14 4kRJyZtgk7UjIRmfBdA/OSVwU76a+tfRjzxEDwj+ojMLCyQwhK20jZrTMKF12/08UGvs e9Kw== X-Forwarded-Encrypted: i=1; AJvYcCWHBDQBJkGrU2QYVoDZwIwHpsJvUlySHVvE+sdt39VhOvyRX//flahbe/Wpv1h15ONVeCMbeOh4lx+9yMJfMxI= X-Gm-Message-State: AOJu0Ywy7Qif2fTA4F9Be1Pv7NgZHnEGYiJWw15aFXFj8i8YChDMmH4m 01xU/bLgMlh0Urt4VrSvoRh5LUPGc6H/kw2uvpgbAtKg7uw2QCQ5hCT9CEOxZHmX/AhVW+dG6xz 0pngG6ZOXdEr9kbi+t33uzu8Wk7mvEq8AW30sBA== X-Google-Smtp-Source: AGHT+IHiSTZONa8cmoVpIG9lzgcOedfJ8exbIMorJI5or/Nes0viYwM34pPgVqcYnKu/WcfLhjNYwaSMKzkSFFhF4/Q= X-Received: by 2002:a17:907:9447:b0:a51:79e9:3d67 with SMTP id dl7-20020a170907944700b00a5179e93d67mr556933ejc.14.1712150599171; Wed, 03 Apr 2024 06:23:19 -0700 (PDT) MIME-Version: 1.0 References: <9o7ss477-q221-on04-4sor-151q11s7s99n@fhfr.qr> <8c4f8e79-67a2-4834-8b8b-d9223716ea89@suse.com> In-Reply-To: From: Christophe Lyon Date: Wed, 3 Apr 2024 15:23:11 +0200 Message-ID: Subject: Re: Patches submission policy change To: joel@rtems.org Cc: Jan Beulich , 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" Content-Transfer-Encoding: quoted-printable 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=unavailable 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 14:59, Joel Sherrill 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=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 ye= ars >> >>> 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 th= e >> >>> expected changes and not some unrelated ones (e.g. caused by user us= ing >> >>> wrong version of autoconf/automake etc.). >> >>> There can be exceptions, e.g. when in GCC we update from a new versi= on >> >>> of Unicode, the regenerated ucnid.h diff can be large and >> >>> uname2c.h can be huge, such that it can trigger the mailing list siz= e >> >>> 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 smal= l, >> >>> 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 ligh= t". >> > >> > 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