Alex said it pretty well, I have a few details to add.
On 2025-03-11 12:09, Richard Stallman wrote: [...]
> 1. **Work Required:** Implementing push requests on Savannah would > likely require significant effort, depending on the current > infrastructure. This seems to be the crucial question, because if this makes the idea impossible, we don't need to study the other questions. I am surprised that "push request" inherently requires a web interface. Why is that required? Is use of a web interface necessary for a technical reason, or is it simply that users of push requests are accustomed to a web interface?
It is a technical reason, but it is also influenced by github's marketing of its "convenient" web interface. Like what Alex said, "pull request" originally means sending an email to someone and requesting them to pull a number of commits from a git server. The term was coined when git was written, and heavily used by large projects like Linux. It's almost like the patch+mailing list workflow, except you only need to send one email instead of 20 patches. But github changed the definition of "pull request": in this workflow, you "fork" a git tree (make an identical copy on the github server) by clicking a few buttons on github's web ui, make some changes on your copy of the git branch, then start a pull request to the upstream by clicking a few buttons on github's web ui. The upstream maintainer then can accept or reject the changes by clicking a button. So by definition, things are done on the web interface.
Could we let each user have a choice of interacting via web or email? The emails for this web interface could be encrypted with GPG Could the web interface be set up on another FSF server and interact with Savannah using the email interface? That would make the new feature modular and thus much easier to develop and maintain.
[...]Like what Svetlana said, Savannah already has a "patch" feature that allows you to post a patch to the web interface, although it's not so convenient that you can one-click merge a patch on the web interface.
It might be possible to implement the feature with an email or an HTTP request, but (1) it most certainly requires significant efforts to develop and test such thing, and (2) it defeats the purpose of "making things more convenient" by the pull request workflow, because sending patches the old way is more convenient and it requires no changes on Savannah.
In addition, there is already free software in the wild that supports the pull-request workflow, and let's not reinvent the wheel. Trisquel project (and PureOS?) uses a self-hosted instance of gitlab and the pull request workflow. Other free software like forgejo also supports it, and forgejo is even more lightweight in terms of resource use, and more free software friendly IMO. But if we want to host forge that supports pull request, gitlab loses lots of functionalities without js enabled, and forgejo becomes very ugly without js enabled (but still might work, 80% of the time).
> they would need to evaluate > existing solutions like GitLab-style merge requests How are these different from push requests?
They are essentially the same thing but gitlab uses a different name for the sake of marketing (I guess).
[...] -- Jing Luo About me: https://jing.rocks/about/ GPG Fingerprint: 4E09 8D19 00AA 3F72 1899 2614 09B3 316E 13A1 1EFC
signature.asc
Description: OpenPGP digital signature
