On Mar 11, 2025, Richard Stallman <r...@gnu.org> wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> I suppose you mean 'pull requests'. > Thank you for correcting me. It seemed to me that what the initiator > wants to do is logically to push to the repo, and that implied it > would be a request to push. *nod*, this nomenclature is often confusing. The way I solve this confusion in my mind is to reason as if the submitter and the committer were at opposite sides of a door, and submitter wants to push the patch in through the door, but can't open it because it's locked, so submitter asks the committer who's on the other side to open the door and pull the patch in. >> 3. github integrated git's pull request machinery with outsourced >> databases and server-side PR management and integration (as in merging) >> interfaces that turn these developer-driven actions into SaaSS, and the >> server-side integration keeps users locked in like flies in an >> enshittified flytrap. > Would you like to describe "management" and "interfaces" more concretely? > What do these features look like to a user? I don't really know, for I've never seen github's in action, but I understand it's a centralized database of pull requests that keeps users locked in, operated through a web interface that offers means to reject or merge a pull request SaaSSily. > Are they attractive to typical users? If so, how? I suppose people who prefer doing their computing under others' control, or who don't get it that merging code is their computing, may enjoy that. To me, being allergic to web interfaces, it's repellant ;-) > Is that integration what draws typical users to pull requests? When > they ask us to support pull requests, are they really asking for this? I really don't know, that's why I asked which of the 3 concepts referred to as 'pull requests' the request was about. Hopefully it's not the github one. > If what they want is that, does it follow that "implementing pull > requests in Savannah" is an incoherent goal? Not entirely. As long as it's GNU developers doing GNU computing on GNU servers, this probably wouldn't be SaaSS, only community's own computing running on community servers under community control. But inasmuchas Savannah is available to host third party's repositories, or its code is available for others parties to host repositories for third parties, that might promote SaaSSy computing models, so this arrangement would be undesirable to enable by default IMHO, or even to support at all. > Could a sufficient subset of this integration be found that would be > both (1) attractive to users and (2) doable within our practical and > moral constraints? Models 1. (pull from submitter's repo) and 2. (PR database with per-PR branches in project's own repo, or from submitter's repo) would be fine, but I don't suppose people inclined to prefer 3. (web-based outsourced-computing (SaaSS) interfaces) would like that. If they want a server to compute their merges for them, they should be encouraged to run their own server. But I guess they don't want to do that either. They *really* *really* seem to have been convinced that giving up control over their computing is not only tolerable, but preferrable. Now, perhaps there's an argument to be made that the computing involved in a merge is reproducible, in the same way that e.g. Guix builds are. If it's reasonable and acceptable to refrain from building your own packages, using others' reproducible builds instead, on the grounds that the result of that computing is expected to be the same, and therefore it's not solely your computing, but a collective activity, then *perhaps* merging patches is just as reproducible and collective an activity as to make it non-SaaSS. The rest of the computing in a repository hosting scenario amounts to no more than publishing and communication, so then it would all be non-SaaSS, even with web-based pull-request handling. Since this is unsettled matter, I've been considering that computing to be SaaSS, but I thought I'd point out that there may be circumstances that could make it acceptable. -- Alexandre Oliva, happy hacker https://blog.lx.oliva.nom.br/ Free Software Activist FSFLA co-founder GNU Toolchain Engineer Learn the truth about Richard Stallman at https://stallmansupport.org/
