Re: Updated Sourceware infrastructure plans

[Joseph Myers <josmyers@redhat.com>]

On Thu, 18 Apr 2024, Mark Wielaard wrote:

> But we like to get more feedback on what people really think a
> "pull-request" style framework should look like. We used to have a
> gerrit setup which wasn't really popular. And we already have a
> sourcehut mirror that can be used to turn your "pull-requests" into a
> git send-email style submission (without having to setup any
> email/smtp yourself): https://sr.ht/~sourceware/

The xz backdoor showed up one issue with some implementations of 
pull-request systems: GitHub removed access to the repository, and with it 
access to the past pull requests, so disrupting investigation into the 
sequence of bad-faith contributions.  I suggest that a basic principle for 
such a system is that it should be *easy* to obtain and maintain a local 
copy of the history of all pull requests.  That includes all versions of a 
pull request, if it gets rebased, and all versions of comments, if the 
system allows editing comments.  A system that uses git as the source of 
truth for all the pull request data and has refs through which all this 
can be located (with reasonably straightforward, documented formats for 
the data, not too closely tied to any particular implementation of a 
pull-request system), so that a single clone --mirror has all the data, 
might be suitable (people have worked on ensuring git scales well with 
very large numbers of refs, which you'd probably get in such a system 
storing all the data in git); a system that requires use of rate-limited 
APIs to access pull request data, not designed for maintaining such a 
local copy, rather less so.

There are some other considerations as well, such as ensuring the proposed 
commit message is just as much subject to review as the proposed code 
changes, and allowing both pull requests that propose a single commit 
(with subsequent fixups in the PR branch intended to be squashed) and pull 
requests that propose a series of commits (where fixups found in the 
review process need to be integrated into the relevant individual commit 
and the branch rebased before merge).

-- 
Joseph S. Myers
josmyers@redhat.com