On Mar 8, 2025, Richard Stallman <r...@gnu.org> wrote: > What do you think about the idea of supporting push requests on Savannah?
I suppose you mean 'pull requests'. > 1. Practically speaking, how much work would it be? Depends on what is being asked for. 1. Originally, 'pull requests' were no more than email messages posted to project's mailing lists pointing at a branch in the requester's own git repository, asking for a project maintainer to run 'git pull <repo> <branch>' to fetch and merge the commits added in that branch, and then push them to the project's git repository. This is trivial to support. For those who don't like email workflows, submitting such a pull request could be as simple as filing a PR (Problem Report, overloaded as Pull Request) with the request. 2. Some projects introduced code reviews integrated with git, so that frequent contributors (with write access to the repository, but not blanket commit privileges, i.e., depending on others' review and approval) would push their proposed commits to specific branches, which would in turn trigger some hook in the project's repository to e.g. email the pull request to a review mailing list, file a PR tracker, etc. git repositories frequently use such hooks to email all pushed commits to a mailing list; they can also reject commits that don't follow a project's branch/tag naming policies, that discard commits from project's main branches, allow only reviewed commits onto main branches, allowing pull/review requests to be pushed by authorized users onto branch trees conventioned for pull requests. 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. IMHO this is a very undesirable featureset, freedom-wise. However, we can get pretty close to github's convenience by using standardized (scripted) formats for "bug reports / problem reports / pull requests", that project's reviewers can query using local (to the reviewers) scripts, pull the changes from unauthorized users' repositories or from project's own pull request branches, give maintainers a chance to review the changes and either approve them, getting the merged change committed and the PR closed, or reject them with feedback, that the submitter should be notified of for being the submitter of the PR. Projects can then publish scripts for submitting PRs, and for reviewers to review them. > 3. Do you see any possible problems that could result from > doing it? Taking PRs from randos (with accounts that enable them to file PRs) may open up the possibility of linking to third-party repositories that we wouldn't want to link to. This is no different from bug reports containing such links, and it could be dealt with as a matter of spam or of moderation. Taking pull requests from committers through git hooks would make our repositories contain the submissions from committers. They're presumably under an agreement about what they can and must not push there. The risks are no different from those that current committers face. -- 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/
