From: Joseph Myers <josmyers@redhat.com>
To: Fangrui Song <i@maskray.me>
Cc: Pedro Alves <pedro@palves.net>, Simon Marchi <simark@simark.ca>,
Overseers mailing list <overseers@sourceware.org>,
Mark Wielaard <mark@klomp.org>, Tom Tromey <tom@tromey.com>,
Jeff Law <jeffreyalaw@gmail.com>,
Jonathan Wakely <jwakely.gcc@gmail.com>,
libc-alpha@sourceware.org, Jason Merrill <jason@redhat.com>,
gcc@gcc.gnu.org, gdb@sourceware.org, binutils@sourceware.org
Subject: Re: Updated Sourceware infrastructure plans
Date: Tue, 7 May 2024 16:17:24 +0000 (UTC) [thread overview]
Message-ID: <1f5a8fc1-6c8-a02f-9787-8bf375a363d@redhat.com> (raw)
In-Reply-To: <DS7PR12MB57651DA3A5C22B2847C13580CB182@DS7PR12MB5765.namprd12.prod.outlook.com>
On Thu, 2 May 2024, Fangrui Song wrote:
> > On the other hand, GitHub structures the concept of pull requests
> > around branches and enforces a branch-centric workflow. A pull request
> > centers on the difference (commits) between the base branch and the
> > feature branch. GitHub does not employ a stable identifier for commit
> > tracking. If commits are rebased, reordered, or combined, GitHub can
> > easily become confused.
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).
* 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.
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).
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.
--
Joseph S. Myers
josmyers@redhat.com
next prev parent reply other threads:[~2024-05-07 16:17 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 23:27 Mark Wielaard
2024-04-18 6:04 ` Thomas Koenig
2024-04-18 8:14 ` FX Coudert
2024-04-18 9:01 ` Christophe Lyon
2024-04-18 11:38 ` Janne Blomqvist
2024-04-18 12:01 ` Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans) Tobias Burnus
2024-04-18 12:32 ` Martin Uecker
2024-04-19 9:35 ` Updated Sourceware infrastructure plans Jonathan Wakely
2024-04-18 15:56 ` Joseph Myers
2024-04-18 17:37 ` Frank Ch. Eigler
2024-04-18 17:54 ` Joseph Myers
2024-04-18 18:29 ` Matt Rice
2024-04-22 15:39 ` Tom Tromey
2024-04-23 2:55 ` Jason Merrill
2024-04-23 3:12 ` Simon Marchi
2024-04-23 3:24 ` Tom Tromey
2024-04-23 3:51 ` Jason Merrill
2024-04-23 8:56 ` Mark Wielaard
2024-04-23 9:39 ` Richard Earnshaw (lists)
2024-04-23 15:08 ` Tom Tromey
2024-04-23 15:25 ` Simon Marchi
2024-04-24 8:49 ` Aktemur, Tankut Baris
2024-04-23 4:06 ` Ian Lance Taylor
2024-04-23 9:30 ` Richard Earnshaw (lists)
2024-04-23 13:51 ` Ian Lance Taylor
2024-05-01 19:15 ` Jeff Law
2024-05-01 19:38 ` Jonathan Wakely
2024-05-01 20:20 ` Mark Wielaard
2024-05-01 20:53 ` Tom Tromey
2024-05-01 21:04 ` Simon Marchi
2024-05-02 15:35 ` Pedro Alves
2024-05-02 23:05 ` Fangrui Song
[not found] ` <DS7PR12MB57651DA3A5C22B2847C13580CB182@DS7PR12MB5765.namprd12.prod.outlook.com>
2024-05-07 16:17 ` Joseph Myers [this message]
2024-05-10 10:43 ` Ben Boeckel
2024-05-01 20:04 ` Jason Merrill
2024-05-01 21:26 ` Mark Wielaard
2024-05-01 22:01 ` Sergio Durigan Junior
2024-05-02 12:54 ` Claudio Bantaloukas
2024-05-02 15:33 ` Pedro Alves
2024-05-03 2:59 ` Ian Lance Taylor
2024-05-04 19:56 ` Ben Boeckel
2024-05-05 5:22 ` Benson Muite
2024-05-06 13:58 ` Ben Boeckel
2024-05-07 16:26 ` Joseph Myers
2024-05-01 21:38 ` Jeff Law
2024-05-02 6:47 ` Richard Biener
2024-05-02 11:29 ` Ian Lance Taylor
2024-05-02 14:26 ` Simon Marchi
2024-05-02 11:45 ` Mark Wielaard
2024-05-01 22:56 ` Tom Tromey
2024-04-23 10:34 ` Florian Weimer
2024-04-22 10:01 ` Mark Wielaard
2024-04-22 13:23 ` Joseph Myers
2024-04-19 9:33 ` Jonathan Wakely
2024-04-22 10:24 ` Mark Wielaard
2024-04-22 11:40 ` Jonathan Wakely
2024-04-23 0:48 ` Frank Ch. Eigler
2024-05-16 15:58 ` Cristian Rodríguez
2024-05-17 13:42 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f5a8fc1-6c8-a02f-9787-8bf375a363d@redhat.com \
--to=josmyers@redhat.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sourceware.org \
--cc=i@maskray.me \
--cc=jason@redhat.com \
--cc=jeffreyalaw@gmail.com \
--cc=jwakely.gcc@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=mark@klomp.org \
--cc=overseers@sourceware.org \
--cc=pedro@palves.net \
--cc=simark@simark.ca \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).