> Given that it would be unaceptable to act the way GitHub does, and > that we can't ccnsider making a repo on Savannah for every change a > user proposes, what is the best form of pull-request that we could > consider implementing?
I've never had an account at websites like GitHub or Codeberg, so I may miss the exact details. These are the stages of a pull request: What you describe is what happens for any change made to a project. * Publishing an initial patchset. On forges like Codeberg, the user forks the original repository using Web UI, clones that fork, pushes into it, then uses Web UI to notify the developers of the original package and point at the changes. This a technicality, when a user does this with a `diff' or `git format-patch' -- it is essentially the same. Since the users can't make a fork on Savannah[*], they could clone the original repository, commit changes, then use git format-patch, submit a new item to a tracker of the package with a tarball of the patchset attached, and point at the parent of the first commit. The major difference between Savannah and Codeforge/etc is one of policy. You _can_ make the same on Savannah, e.g. by using a mailing list. That wouldn't be much harder than on GitHub, but it would be unlike on GitHub. [*] They could make a fork on an independent site like repo.or.cz but I shan't consider this possibility. * Discussing the patchset. As far as I understand, current Savannah trackers support this adequately (or can support if any features are missing). It does not, literally all projects that use Savannah use something else. * Publishing updated or alternative patchsets. Likewise, the users can make changes in their local branches and attach new tarballs with patchsets when commenting in the trackers. Same as publishing on a mailing list. Again, this isn't considerably more complicated, but it's different. * Applying to the original repository. On forges where users can fork repos, the developers can do that using Web UI. I guess then the website can see the points in the commit tree where to apply the patchsets and merge or rebase them in the original repository. If we want people to do their processing locally, then What does locally mean in the context of applying a the change? the developer would download the tarball with the patchset, unpack and apply it to the right branch, then push the result to Savannah. Why would the developer download the tarball when they are sitting on the code base that is being worked on? * Closing the request is trivial, so I don't discuss it. To tell the truth, I can see little in this workflow we could 'implement' to simplify the actions. You've put much sticks in the wheels to outright make it impossible to accept projects into the GNU project, but you think that making it outright impossible to work on a project to simplify it .. we could write guidelines about those procedures, but then every Savannah group may have their own specifics like the tracker to use (bugs, support requests, tasks, or patch), and---more important---users don't like reading guidelines. This is from someone who cannot even follow simple guidelines ...
