From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 96187384604F for ; Wed, 3 Apr 2024 13:23:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 96187384604F 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 96187384604F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::532 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712150602; cv=none; b=FYcEyUOLRDntS/zrz4yTKyx9HSRzQjF848USYnog49G/NtzQJR1ws+OOvz3EB/R8Cjd6kalRY4L7HncOI7tBN8hhiiQDcra7ek7F8WhWvmqhqQ1W7nvxyfDEi0ejQ4oGhkEX94tskB3toKLI+e5Z6Df1nPXGz3zHuOCnw5kbHls= 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=aOqOERzaa5317ImA4zqwHE2fnNHuNbRX8QcYG+PrdNC3FEgwKRxpliQPYd1Fu7DF4qn4fwUaWczHULMpuxk8GeQoLpS4O/a8atE0S9vOdnhpEY/y0HcfQN6Al0jLvH5fJK1ZlNCBrhkriNAYtDzObdQ3XqnlrqJYqDL+l5eQzTw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-56c1922096cso8067622a12.0 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=sourceware.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=pw+BPIuIwiBieldtj8snsctZgjG7iwhfl7baICTSgjN7ZVOTIbd8WfrHELz2hLF3s3 ZtEvqG+o9s6HL/SorJKGH3DeC3mnM+2fcJyvjMp2SGRpA2zcsxY75knlpHvZJ/yo4b1R Lkumf/33z4RRQT80Nhkx2COoJCvn/3K71VlfUnhxiIUKfO9GAxpkHatZfskE3Lla3QCM kpjtVHy/z7TjGU07bYz/J4CNiPLQS3d+fIQ1qHYdPqjCygO1dEjVLEIZx5lTlhXprgMr zZTlUcOX49i0OweyAXJf0bGIV6mJWAQz3FvbnvBWT1olYuVJ7tpka/ybcaC9gO5g/D2A txGA== 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=bbKofQjDcfw8JVYwLFqBm6Glvz0k+jtfDx33cbfU3GLlIIVxd8NQtO/xBGkXfQX8vu m/sX/qYpkSpAxN/BdCU4vnMpYXIf5e1iofH+97j+SralhwglW0XWZm1Lg4yricYmxubn FNKjZtsAoEhH7it+VLaSQ/pDNhD6GpBq/xnn4McvjHmq12MYzzxhvK3pJGdBlfCpQJrk tPRLqT3OnZvb5/xeNHxOrEKYZt0pWxe2vt8l3DuownNOIISAniSlOEfoYm6z30x+Zqt/ L5fW0GcEOexBGcNvwhUGnou2TvqaoSzNGqFVdX07/Fn7YRS2vBORlA34E6FEiP+1vW+p If4Q== X-Forwarded-Encrypted: i=1; AJvYcCVaXtmshihIpvBXcRXIPV4I+RfaMbz8V8b1b+IYo/3+gS/UPkO1wHFVpcybGqlF3PoopxCUIz2SeNsRqTTQa7BvBec= X-Gm-Message-State: AOJu0YzYBsWLEgRFTz/exSvpDG+s9w5guO6f0dWpr9Aj/OEHmXq5nJIF I0nHFYsmWc/I6ST4FVDibxEQIht8oJGRZ9LIh44O/t8mss0DdPGyFEWAkXp8RU3O4DMG1Zg7kfG OcE0Lhj+YfQbIedXC3g2sW8IqQu9PFxIhKZXbNw== 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.2 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=ham 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