From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yGdvLor6PWaO7QwAWB0awg (envelope-from ) for ; Fri, 10 May 2024 06:44:26 -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=F+up7F0K; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B8D301E0C1; Fri, 10 May 2024 06:44:26 -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 96CEF1E030 for ; Fri, 10 May 2024 06:44:24 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F21FB3842FD6 for ; Fri, 10 May 2024 10:44:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F21FB3842FD6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1715337864; bh=N9RXSKrOmmbyvwPx1eDq90F5Zpk/etPBhYd+4gvgSgg=; h=Date:To:Cc:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=F+up7F0KkU1e2TDRspXmT8WRbBeoXZeaPrRk09MPmcECXUpT5+oYucVbQ7Fv4y+5C joQmX7iG6usaVD2PBrTahCl+H0mlqTiuTAWpt0ZwC15KsAZwXkYNW7DHLd7iZQXpgv f0zx0diUiF14wewfnqeAu149VlvVQQIS30l8uw0A= Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) by sourceware.org (Postfix) with ESMTPS id 07D523849AE7 for ; Fri, 10 May 2024 10:43:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 07D523849AE7 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 07D523849AE7 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715337810; cv=none; b=RsqSykvUMiKyrb1ymYeXoCre+gRaPJy8x/ORuSgCFvrxABPOoQuYhvm9w49cRAtZYBg7Pkca/BeWM56vgnND/FNejyiMEzUaEZ+3VCqKXA2WicUHCRc7kFe50XDEmu+PxSt0K7G7fu5ZwcwlVafy3X0+mVv1n3foRldYXPdhbWo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715337810; c=relaxed/simple; bh=THtykoBRcmykyg1Oe/BtBm/gsjPrKawNyVUOY41JybA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=V6dbnRVFvp1L4qqRFKt4AaH4MMb0Ja4r+Bc+FwUo4s5pO4CpuxsxXMQY9jJU5Oh52wXwn2EPsExiLubh6F+ffyUpl1akmMSO8tQuk3iZGqqJ/i9EoW9ak0CKB3QddpRRhD4VFvYNXiD8/QfJqCGWO9DHc3crjkMNyxaUmaUbqys= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-69b50b8239fso16330756d6.0 for ; Fri, 10 May 2024 03:43:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715337807; x=1715942607; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=N9RXSKrOmmbyvwPx1eDq90F5Zpk/etPBhYd+4gvgSgg=; b=Q0E8Dvy8oOzEydwTXUKZTNFvgf6rTH2uKawhTxjlcHTQn1U1lzuOMcdkwWy0t63yp2 bZwKTwUXfo5IkK33sh0ciYeUDv3qFQJ+DQOhpBXBTwsaw7+hotJzFKYxJbgduf7Qkon0 fD0z9aVgKP4LOzaa/GESioeTMKLxssbsYxe9WHfOrGEp0m2waezEHkbat34Zj9w8ECIj B9QFb0Vw/tpVdbeAtE0TOSI+JV7Vx6kk66SlokiSQGcCDKDG3V2Hg5u/Dgc8OvaU9Kde 6dkvXIjK4zhLAllXAMcDXcvlOtph94N7wgU+2P6XNs/l8/fzCtsmWXbCCaW/bebyTWz/ 2edA== X-Forwarded-Encrypted: i=1; AJvYcCX2j+Z+y/XMdpiaVRiWfwL5WhFPyVL+8VkKv8vDZzMqxzxkuSgtn34MJTRHujUB/Dnainy6ZTESYYO+I2sm/uFVmQ4= X-Gm-Message-State: AOJu0YyPLUtdMeaFix0dW23/K5eBbunII/WU6IsV6GiBL6DPV/hvi+A+ YAimIH6KdC+Zjg2i2Vo7F011uhke2L8aIyLcxsK5TFg+rZhIXgsB7BkJBl7nFg== X-Google-Smtp-Source: AGHT+IFvioho1MgNH9xe1q0UrPuEOwpmG+70rr0o9qCM0D2dSj5+EVqwbmMTFHAn6m0C3LXwQltH8g== X-Received: by 2002:a05:6214:3f8c:b0:6a0:eb86:f5e with SMTP id 6a1803df08f44-6a16793bd96mr42035146d6.17.1715337807264; Fri, 10 May 2024 03:43:27 -0700 (PDT) Received: from localhost (syn-142-105-146-128.res.spectrum.com. [142.105.146.128]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6a15f1ff124sm16097826d6.138.2024.05.10.03.43.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 May 2024 03:43:26 -0700 (PDT) Date: Fri, 10 May 2024 06:43:25 -0400 To: Joseph Myers Cc: Fangrui Song , Pedro Alves , Simon Marchi , Overseers mailing list , Mark Wielaard , Tom Tromey , Jeff Law , Jonathan Wakely , libc-alpha@sourceware.org, Jason Merrill , gcc@gcc.gnu.org, gdb@sourceware.org, binutils@sourceware.org Subject: Re: Updated Sourceware infrastructure plans Message-ID: References: <87wmooep76.fsf@tromey.com> <0347e05a-94c6-4ecc-aa8f-cc90358a813d@gmail.com> <20240501202008.GA6469@gnu.wildebeest.org> <874jbh45l8.fsf@tromey.com> <64d0e314-f4e9-4c63-90dd-67a05749e12e@simark.ca> <9a7111c2-d570-4d26-8fe9-f34834ae1eab@palves.net> <1f5a8fc1-6c8-a02f-9787-8bf375a363d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1f5a8fc1-6c8-a02f-9787-8bf375a363d@redhat.com> User-Agent: Mutt/2.2.12 (2023-09-09) X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 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: Ben Boeckel via Gdb Reply-To: Ben Boeckel Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Tue, May 07, 2024 at 16:17:24 +0000, Joseph Myers via Gcc wrote: > I'd say we have two kinds of patch submission (= two kinds of pull request > in a pull request workflow) to consider in the toolchain, and it's > important that a PR-based system supports both of them well (and supports > a submission changing from one kind to the other, and preferably > dependencies between multiple PRs where appropriate). The way I'd handle this in `ghostflow` is with a description trailer like `Squash-merge: true` (already implemented trailers include `Backport`, `Fast-forward`, `Backport-ff`, and `Topic-rename` as description trailers, so this is a natural extension there). Alternatively a label can be used, but that is not directly editable by MR authors that are not also members of the project. There's also a checkbox either at MR creation and/or merge time to select between them, but I don't find that easily discoverable (I believe only those with merge rights can see the button state in general). > * Simple submissions that are intended to end up as a single commit on the > mainline (squash merge). The overall set of changes to be applied to the > mainline is subject to review, and the commit message also is subject to > review (review of commit messages isn't always something that PR-based > systems seem to handle that well). But for the most part there isn't a > need to rebase these - fixes as a result of review can go as subsequent > commits on the source branch (making it easy to review either the > individual fixes, or the whole updated set of changes), and merging from > upstream into that branch is also OK. (If there *is* a rebase, the > PR-based system should still preserve the history of and comments on > previous versions, avoid GCing them and avoid getting confused.) > > * Complicated submissions of patch series, that are intended to end up as > a sequence of commits on the mainline (non-squash merge preserving the > sequence of commits). In this case, fixes (or updating from upstream) > *do* involve rebases to show what the full new sequence of commits should > be (and all individual commits and their commit messages should be subject > to review, not just the overall set of changes to be applied). Again, > rebases need handling by the system in a history-preserving way. There's been a long-standing issue to use `range-diff` in GitLab. I really don't know why it isn't higher priority, but I suppose having groups like Sourceware and/or kernel.org interested could move it up a priority list for them. https://gitlab.com/gitlab-org/gitlab/-/issues/24096 FWIW, there's also a "comment on commit messages" issue: https://gitlab.com/gitlab-org/gitlab/-/issues/19691 That said, I've had little issues with rebases losing commits or discussion on GitLab whereas I've definitely seen things get lost on Github. I'm unfamiliar with other forges to know there (other than that Gerrit-likes that track patches are generally workable with rebases). > GitHub (as an example - obviously not appropriate itself for the > toolchain) does much better on simple submissions (either with squash > merges, or with merges showing the full history if you don't care about a > clean bisectable history), apart from review of commit messages, than it > does on complicated submissions or dependencies between PRs (I think > systems sometimes used for PR dependencies on GitHub may actually be > third-party add-ons). The way I've tended to handle this is to have one "main MR" that is the "whole story" with component MRs split out for separate review. Once the separate MRs are reviewed and merged (with cross references), the main MR is rebased to incorporate the merged code and simplify its diff. This helps to review smaller bits while also having the full story available for viewing. > Pull request systems have obvious advantages over mailing lists for > tracking open submissions - but it's still very easy for an active project > to end up with thousands of open PRs, among which it's very hard to find > anything. In CMake, the mechanism used to keep the queue manageable is to have a `triage:expired` label for closed-for-inactivity (or other reasons) so that closed-but-only-neglected MRs can be distinguished from closed-because-not-going-to-be-merged MRs. The "active patch queue" tends to stay under 20, but sometimes swells to 30 in busy times (as of this writing, it is at 10 open MRs). --Ben