LibreServer Blog / Patches over the Fediverse

Epicyon now has the ability to post and receive git patches. If you make a commit to a git repository and then use the format-patch command and paste the result into a new post in Epicyon then you can send patches to other people over the fediverse. On the receiving side they will appear shown in a monospace font. This only works if you include the name of the project within the CW/subject line and on the receiving side the project name needs to be added within the profile settings (i.e. you need to opt in to receive patches for a project).

When a patch is received it will be put into a patches subdirectory within the users account directory. This can then be applied in the old-fashioned manner, or you could have a script do something with the incoming patches.

So this provides a non-centralized way of receiving git patches, other than via email. There is however a small problem. The character limit on most fediverse instances isn't big enough to be able to paste anything other than the most minimal patch. So that's a fundamental obstacle.

Why bother with the fediverse as a way of transferring patches? The traditional decentralized way of doing software collaboration, which is still used by the Linux kernel, is via mailing lists. But for that workflow to perform well you really need to be on top of your email client with your procmail rules tweaked to perfection. Not everyone is at this level of ubergeekdom. Also keeping spam out of mailing lists can become time consuming and demoralizing. By contrast leveraging the existing moderation and http signature features of the fediverse means that many of the problems with the traditional development model can be averted.

I've also been reading the ForgeFed specification. It doesn't look as if this has had much uptake, and reading through the various issues I can see that there have been years of argumentation with very little implementation. Crucial features such as pull requests appear to have been forgotten about entirely.

So I might divert some effort into making a git server which is genuinely decentralized but doesn't depend upon using mailing lists. I could use the existing ForgeFed framework and add in the parts of the spec that are missing. This would help with other projects, because it has to be admitted that my current collaboration workflow is less than ideal. People can make pull requests on GitLab mirrors, but then there isn't any straightforward way to get those upstream to my own server.