From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id P+2ULSoSDWZSIyEAWB0awg (envelope-from ) for ; Wed, 03 Apr 2024 04:24:10 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=rT/bWhD8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A8EB31E0C0; Wed, 3 Apr 2024 04:24:10 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 92A761E08C for ; Wed, 3 Apr 2024 04:24:08 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 191513846410 for ; Wed, 3 Apr 2024 08:24:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 191513846410 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1712132648; bh=fZ0Ykr9db+CsTI6dwTuEYs30wV/BzbOIarwxpevxEnk=; h=Date:Subject:To:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=rT/bWhD8mTEZHhUUSdijJghTKuYGzyA5H+DKqbu4Ec258SO/blQXkNDjX7cSg7Z2R f+fL9Ev9ZqTcPADMx44v1uqLjdyDLiieknhxXvLdfeF5efUGidex3hG/7Hgxf06ryq DjQP94aa1XKQVj3GTs2UysgotAQCD/TVRn+Mq3n4= Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 1943B384772B for ; Wed, 3 Apr 2024 08:22:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1943B384772B ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1943B384772B ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712132556; cv=none; b=Q2dmV2Rjroqzg9LtPRRqBueDxbcOP/yhKPuJzWltH5H7X2dx82gtto+KJXWXO8VFsbR7uVVzMvO6LMQTQoYGFV3hIVvPfzd4j1oJeQlKdA0ZLBKRz1qQTZOCkHXcVo3d2KGjbgATslbWhTJmUDWUL/ru2uW1K3iwOY+ez8tBPIk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712132556; c=relaxed/simple; bh=BZMn75XgI2+o4bDWSmaPZ0MfVUDUF0dnRa6LBpdY8Xw=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=hXt2xF9FH4ASCOH28c9i8ntid3XlRnI7o/Vx756By6snarp+DknozuTjOjWjL/231U4mu1aWdXxNLbeiDIa26Wv/1QKFx7O0iveRUn+le2jv6l8SCtWFF5Lzql+4Bt6JzSiTntusnrseLJywLbazBEY3T6QHMmTTmTapV2XYlIw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a4702457ccbso767830166b.3 for ; Wed, 03 Apr 2024 01:22:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712132552; x=1712737352; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fZ0Ykr9db+CsTI6dwTuEYs30wV/BzbOIarwxpevxEnk=; b=YlDHgxy1CNPyuhXmXOjnpS+5sOfJN1/4PWo5V+LH/+n0/32unG25PHljJVtXPS3+ts gvR92i+CbqBpfglJNBmqnu26wlSxg3NCR+CMxNRbR831WYq7L9F3wUnogmGhoYI6H0Qr 2hkUWw1uDL4TnhAxYeKV0EF8rbRb49kZJhB0L675bLeIRGX1uN0cG+Rw0la3y50TaP+7 W2FBtFFNAi2d0ZrLtY711mmC523lmGz2RA76pcD2Vm5xNm7P3eUTjk6y7IcCLpTOp7lI m9GjTIzRk5AM8qyr+qf3TT+GlUm28qN3yS1kOiES7ZAYd3CyJgWypK6jMbtFN1cCU4KJ 1MQw== X-Forwarded-Encrypted: i=1; AJvYcCWnFjhjKS38rp1PFPP1rESwIX8EJ52N6pOq6E0GuMCzEIF98JXoFoGz9RdqeUtnagwEOtkCmR3XQ0QEYCvDCwuTir4= X-Gm-Message-State: AOJu0YweXNiJPv9vVutsKdxk4h/GpVWiSN7k1GUuqJ4Ng3d3A8Ixx3Wz B0RTGIVW1+irUOV+ugyFVoMiqqfM7dqcbixI5BEuzR9Dv6dWZf7kslOhROJxQgb30+z04i2Arfv sjVOl4CYKAW9h8dFzd7oA1Lg3gPvD5EHb41Ep0Q== X-Google-Smtp-Source: AGHT+IGwE6cRDJS1sZuSCAU4AwVp2Xge9Je31IaFtNfOd889wet/umuKawQcO4oNsdhUzkTNpZq5JKDEGR7e1pd5IkI= X-Received: by 2002:a17:906:7245:b0:a4e:2269:bc21 with SMTP id n5-20020a170906724500b00a4e2269bc21mr9653459ejk.1.1712132551828; Wed, 03 Apr 2024 01:22:31 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 3 Apr 2024 10:22:24 +0200 Message-ID: Subject: Patches submission policy change To: binutils@sourceware.org, GCC Mailing List , gdb@sourceware.org, Nick Clifton , Richard Biener , Jakub Jelinek , Joel Brobecker , "Carlos O'Donell" Cc: Maxim Kuvyrkov , Thiago Bauermann , Adhemerval Zanella Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_MANYTO, 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 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Christophe Lyon via Gdb Reply-To: Christophe Lyon Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Dear release managers and developers, TL;DR: For the sake of improving precommit CI coverage and simplifying workflows, I=E2=80=99d like to request a patch submission policy change, so that we now include regenerated files. This was discussed during the last GNU toolchain office hours meeting [1] (2024-03-28). Benefits or this change include: - Increased compatibility with precommit CI - No need to manually edit patches before submitting, thus the =E2=80=9Cgit send-email=E2=80=9D workflow is simplified - Patch reviewers can be confident that the committed patch will be exactly what they approved - Precommit CI can test exactly what has been submitted Any concerns/objections? As discussed on the lists and during the meeting, we have been facing issues with testing a class of patches: those which imply regenerating some files. Indeed, for binutils and gcc, the current patch submission policy is to *not* include the regenerated files (IIUC the policy is different for gdb [2]). This means that precommit CI receives an incomplete patch, leading to wrong and misleading regression reports, and complaints/frustration. (our notifications now include a warning, making it clear that we do not regenerate files ;-) ) I thought the solution was as easy as adding =E2=80=93enable-maintainer-mod= e to the configure arguments but this has proven to be broken (random failures with highly parallel builds). I tried to workaround that by adding new =E2=80=9Cregenerate=E2=80=9D rules in the makefiles, that we cou= ld build at -j1 before running the real build with a higher parallelism level, but this is not ideal, not to mention that in the case of gcc, configuring target libraries requires having built all-gcc before, which is quite slow at -j1. Another approach used in binutils and gdb builtbots is a dedicated script (aka autoregen.py) which calls autotools as appropriate. It could be extended to update other types of files, but this can be a bit tricky (eg. some opcodes files require to build a generator first, some doc fragments also use non-trivial build sequences), and it creates a maintenance issue: the build recipe is duplicated in the script and in the makefiles. Such a script has proven to be useful though in postcommit CI, to catch regeneration errors. Having said that, it seems that for the sake of improving usefulness of precommit CI, the simplest way forward is to change the policy to include regenerated files. This does not seem to be a burden for developers, since they have to regenerate the files before pushing their patches anyway, and it also enables reviewers to make sure the generated files are correct. Said differently, if you want to increase the chances of having your patches tested by precommit CI, make sure to include all the regenerated files, otherwise you might receive failure notifications. Any concerns/objections? Thanks, Christophe [1] https://gcc.gnu.org/wiki/OfficeHours#Meeting:_2024-03-28_.40_1100h_EST5= EDT [2] https://inbox.sourceware.org/gdb/cc0a5c86-a041-429a-9890-efd3937606e5@s= imark.ca/