Re: Updated Sourceware infrastructure plans

[Joseph Myers <josmyers@redhat.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