From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by sourceware.org (Postfix) with ESMTPS id 022693849ADE for ; Fri, 10 May 2024 10:43:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 022693849ADE Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=kitware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kitware.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 022693849ADE Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::f36 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-xf36.google.com with SMTP id 6a1803df08f44-6a0ff97a9c7so22550866d6.0 for ; Fri, 10 May 2024 03:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kitware.com; s=google; t=1715337807; x=1715942607; darn=sourceware.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=N9RXSKrOmmbyvwPx1eDq90F5Zpk/etPBhYd+4gvgSgg=; b=PCKM7CXevJVRLBh5Gt4qXhNZYKSCHkmq0gIcDhFCdN7Ei3lmE276WhMeTpui0wfR+G b2Wmp08TxaqI1AEut8YyuLs0mucFwxpFzQF0503BeKjK68Gnv+d+Qz0OocqcbLUIpooA m11SrF1JIMkHXbuuwKcviOoAcL35sdiFXb4NU= 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=v1tTZS4kvPrfMlmH4UyzFL5Qm245LqRP9ar0N4yg0xIhbe6cLC60Mc1yWcQ7FYD6Ol dEtuS1YV7kpIExn3m34ZPtMDiNbRq2aKHg//IyP7ziyqDP48ZTvIXQQmo0i0ic6D/m9v OJL2AZ+pNQg243AVhwIef56rHxS7XtObqMongjx72nSk4sFlpHahwAaeqflrihzX41P4 BBq8+IV5lMSj3hys4VemUDPHlRuuQA5H3EKSxuJkWnsiuZxm2rK3alECtIX7snGS7Fiu RnPmBMrD3aBoTiatoE1JRCtOaq99tSXS+0u7SiG64wXGicHlTQeyICEQ509hOZOy3epo AlkQ== X-Forwarded-Encrypted: i=1; AJvYcCU3/aoB4/52nRTQdhEzvOO2IQVk8lAvb1kj5mEh/4igETbAmHx0zqVQoTdybYR3E1vuLEJUHE9OqQ+GnMo7GIlbbkyxjLNQQG9g X-Gm-Message-State: AOJu0YzlT6i+e9MySB/PNsdHpJLQozXzJIIk2rvn7henwcr2647QMHAs CD/wh0sboqzKQWwkMqEvXk1JfnIV4u9mmo/sTDTO7x0dyheLmlEs4uEhNz9FZw== 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 From: Ben Boeckel 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 List-Id: 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