Re: On pull request workflows for the GNU toolchain

[Matt Rice via Gdb <gdb@sourceware.org>]

On Thu, Sep 19, 2024 at 3:52 PM Joseph Myers via Gdb <gdb@sourceware.org> wrote:
>
> 1. Introduction
>
> This message expands on my remarks at the Cauldron (especially the
> patch review and maintenance BoF, and the Sourceware infrastructure
> BoF) regarding desired features for a system providing pull request
> functionality (patch submission via creating branches that are then
> proposed using some kind of web interface or API, with a central
> database then tracking the status of each pull request and review
> comments thereon automatically),

I wasn't at Cauldron, but

I just wanted to say that a lot of the web-based interfaces (git-lab,
github, gitea, gogs, etc) for providing pull request functionality
pre-date the existence of git-protocol features that also allow you to
implement the pull request type behavior, the git proc receive hook
https://git-scm.com/docs/githooks#proc-receive
can be used to implement a pull-request style workflow without the web
interface. This is somewhat going against the grain,
and has a less developed ecosystem of clients/servers/hosting
resources, I haven't kept up to date with what tools are actually
available,
last I looked though the only tool I knew of using it was
https://git-repo.info/en/ for the client, and I written a prototype
implementation using the hook as a server
(as far as I know the only other server tools using this are the
proprietary codeup.aliyun which might be internal to alibaba?).

To me though it is nice being able to edit the PR cover letter
directly in the editor, and do the pull-request using command line
tools.
What draws me to this however, is that it allows me to set up an
in-house review process using the same set of tools that eventually
feeds into upstream while mirroring the CI architecture locally.  That
is the dream anyway and in my opinion represents the style
of pull request workflow we should be aiming for if we want something
ideal.  Anyhow, IMO a big reason why all of these workflows are so
centralized
is just that they are going outside the git protocol.  To me the work
that has been done seems promising as a proof of concept distributed
pull request system,
and what it is probably lacking is putting an actual web-based
interface on top of the git protocol based design and a lot of spit
and polish.

At least to me the whole sourceware ecosystem feels like an ideal
candidate for this, since it is much more common to have ports in
progress to unfinished or unreleased instruction sets,
than would happen with almost any other piece of software. So there is
some amount of justification for going against the grain of a
centralized system imo.