Re: irt: Re: Core statement on version control systems

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Oct 09, 2025 at 10:59:16AM -0400, Andrew Cagney wrote:
 > > > Right, the "pull request" issue.  Where github serves as an example of
 > > > how to not do things.
 > >
 > > Sing it!
 > 
 > Greg is right.  My grype is with github.  gitlab, for instance, feels
 > better but I don't use it everyday.  bitbucket comes with baggage.

github and gitlab are effectively indistinguishable.

 > Submission should come in via pull-requests and not a series of
 > patches to a mailing list.

There are a lot of possible ways to submit patches. Pull requests as
such are one very specific way that isn't a mailing list. I'll
certainly agree that sending patches to mailing lists sucks. But it's
not like these are the only choices.


On Thu, Oct 09, 2025 at 02:34:18PM -0700, Greg A. Woods wrote:
 > At Wed, 8 Oct 2025 23:46:38 +0000, David Holland <dholland-tech%netbsd.org@localhost> wrote:
 > > It's a terrible model for development, and not even a good way to send
 > > patches upstream to random projects.
 > 
 > Unqualified assertions don't make something so.

Pointing that out doesn't make it not so.

 > Regardless it's not really your's to say -- it's the way "everyone"
 > expects things to be done these days

Yeah, like using Windows 95 thirty years back...

 > On the other hand I would like to understand your complaints on this
 > issue better.

Github pull requests are a fine way to send ten-line patches to random
projects you aren't part of, provided you've already signed up for
Github. If you haven't, that's a much bigger barrier than creating a
transient login in someone's bugtracker.

My experience doing so has generally been that they get ignored until
they're stale enough to justify summarily closing them. However,
that's just what most upstreams are like.

Pull requests are, though, a terrible vehicle for doing real work:

 - Compared to just committing (or committing and pushing) they're a
   lot of extra administrative frobbing. You create a new branch, you
   commit, you push; then you have to stop what you're doing, go open
   a browser, log into github, navigate to the right repository, then
   fill out the form to make a new pull request. Then you have to go
   do something else for a few hours until a coworker gets around to
   hitting "approve"; then you have to stop and go over to the browser
   again and find the pull request to merge it. Then you need to go
   back to your tree and do a bunch of extra git frobs to pull the
   merged changes back and get to the state you would have been in if
   you'd just committed and pushed.

   In NetBSD small changes involve "cvs commit -m 'typo in comment'".
   Doing the same in the pull request model requires an incredible
   amount of administrative overhead. Consequently, in projects that
   are run on the pull request model, small changes just don't get
   made, or get quietly rolled into other changes that now you can't
   pull up/backport/cherry-pick. This has real costs.

 - That's the best case, though. There are many ways it gets worse:
   management often insists on a ticket for every pull request, so you
   have twice as many forms to fill out. And then often the branch has
   to be named after the ticket number, so you have to go back and
   forth to the browser multiple times. Then also it's common to
   require rebasing on head before merging (in which case you usually
   also have to wait again for a coworker to reapprove!), or requiring
   merge-squash (in which case you can't even amortize the cost of
   filling out the forms over lots of changes).

 - An unmerged pull request is properly thought of as a patchset, but
   pull requests are made of commits. This both weakens the model of
   what "commit" means (in the git/GH world it no longer means "this
   change has now been made and we are committed to it"), which isn't
   good for the way people think about what they're doing; and it also
   makes it unnecessarily hard to revise the patchset. One can retcon
   a pull request branch with git rebase -i and git push -f, but it's
   a *lot* messier and more awkward than, say, the quilt model.

 - The model is intended for semicompetent juniors who can't be
   trusted to commit to the trunk without adult supervision. There are
   two problems with that; one is that it's a horrible commentary on
   the world and we ought to be able to figure out how to do better.
   The other problem is that it trains juniors to work that way, and
   it's very difficult to work through the systemic limitations to
   teach folks to be better than that.

Then there are also defects in the GH implementation (which as far as
I know are all shared with gitlab, because they have the same
operating model):

 - There is no way, at least with GitHub Actions, to build and test
   every commit in a pull request in CI. It will only operate on the
   tip.

 - GH at least no longer just throws away review comments when you
   force-push. However, it has no clear model for which or how many of
   the various versions of your pull request it retains, or for how
   long. Also, it could distinguish between force-pushes that rebase
   on the trunk and force-pushes that rearrange the patchset (and
   refuse or flag force-pushes that do both at once) and even
   illustrate the resulting changes coherently (such as telling you
   which merged pull requests on the trunk got rebased over, or giving
   commit-by-commit reports of the rearrangement you did) ... but
   it does none of these things. Some of the things one could imagine
   wanting it to do would kind of require fixing git's underlying
   model of revising the patchset with rebase and force-push, but by
   no means all of them.

 - It's possible to review pull requests one commit at a time or via
   the overall diff, which is good. However, when you review one
   commit at a time it doesn't warn you when you're commenting on code
   that changes again in later commits (let alone give a quick way to
   show such changes...) and also, sometimes comments made one commit
   at a time show up in the overall diff and sometimes they don't, and
   therefore one has to be careful not to miss them. (This is
   sometimes related to whether the code you comment on has been
   changed again later. But not always, and it isn't super clear why.)

Then there's also the issue that if you're using GitHub, and certainly
if you're using GitHub and pull requests you're using it as a central
repository and not taking advantage of the distributed ability of git.
Which in turn means you're paying a lot of costs (like commit hashes
instead of versions) for functionality you aren't using.

 > Perhaps you could expand on how you would like to move from GNATS and
 > mailing lists to something more modern involving a true distributed
 > version control system that can give third party contributors better
 > access to project change history and allow better direct integration and
 > cooperation with core developers in order to help keep NetBSD up to date
 > and to support its development.

As a patch submission system GNATS isn't even a failure. As I said in
my earlier post, we should have some kind of patch submission system.
I don't know what. I don't think GH is a good model for what a project
hosting system should look like; I think it's an even worse model for
what the (external) patch submission system for a larger project like
NetBSD should look like.

For _internal_ use we need at least two other things that are
different from an external patch submission system: a way to review
drafts of large or controversial patchsets, and a way to review
commits after they're committed.

For the first, it is in fact really hard to beat replying to an email
and quoting sections; but that only works with a traditional
mailreader and not with say gmail. For people stuck in the
enshittified webmail environment, we should probably have something
else.

For the second we have source-changes-d and it kinda sucks, but the
reasons it sucks are at least independent of the version control
tooling.

(And that's quite a sentence you've got there. Maybe include a comma
next time. :-) )

 > > Also, realistically, someone who can't manage to figure out a
 > > different patch submission mechanism probably isn't going to be a very
 > > successful contributor.
 > 
 > The problem is they're not even going to take a _first_ glance at the
 > project if it isn't doing the git(hub/forge) dance.

Maybe, maybe not. I don't know about you but I don't choose software
to use based on whether I can find its github.

-- 
David A. Holland
dholland%netbsd.org@localhost