From ed07bf687c91f27ed43666f49d040c87b577c972 Mon Sep 17 00:00:00 2001
From: Jordan Bancino
-Submitting patches is fairly easy to do if you've got the CVS sources -checked out. Once you have made your changes, just run +Telodendria aims at remaining as minimal as possible. This doesn't +just mean minimal code, it also means a minimal development process, which +is why Telodendria doesn't use GitHub, GitLab, or even SourceHut. +Instead, the contribution workflow operates on submitting patch files to +a public Matrix room, sort of like the OpenBSD project operates on patch +files sent to a public mailing list. +
+
+If you're not used to manually creating and submitting patches instead of
+opening a "pull request," you should be pleased to hear that submitting
+patches is fairly easy to do if you've got the CVS sources checked out.
+In fact, I find it easier than having to make a GitHub account, forking
+a project repository, and then making a pull request for it. Once you
+have made your changes in your local copy of the code, just run
cvs diff
:
-Then, send the resulting patches to
-#telodendria-patches:bancino.net
, where they will be
-promptly reviewed by the community.
+At this point, it would be a good idea to open up your patch file in
+your preferred editor and look it over to make sure everything looks
+good. While you have the file open, you should also add some
+email-style headers to the top of your patch file, for quick
+identification:
+
+Obviously, set the actual values to your own information. From
+should be your name and Matrix ID, and Date
should be in the format
+%Y-%m-%d
. The Subject
should very briefly
+describe what the patch is about. Below these headers, write a more in-depth
+description of the patch.
+
+Then, send the resulting patch file to
+#telodendria-patches:bancino.net
, so it can be
+discussed and reviewed by the community. If you don't have a Matrix
+account, and you really don't want to create one—ignoring
+how odd it is that you are trying to contribute to a Matrix
+homeserver project—you can email your patches to
+jordan@bancino.net. However,
+the preferred way of submitting patches is to the official Matrix room,
+so I will upload your patch there along with your email address. If you
+are going to send patches via email, they must be plain text emails,
+and the patch must be in the main body of the email. No MIME, base64, or
+printed-quotable garbage. I will silently reject emails that are not
+purely plain text. I should be able to write a raw copy of your message to
+an mbox
file, and then apply it onto my code right from
+there, with no further processing. If you're going to be a regular contributor,
+it would just be easier to create a Matrix account. It doesn't have to be
+on my public homeserver, but it certainly can be. Note that the discussion and
+ultimately the decision on what to do with your patch will all happen in
+the Matrix room, so if you submit patches using email, you'll miss out on
+any feedback.
+
+Try to keep your patches on topic—make one patch file per feature +or bug fix being implemented. It is okay if your patches depend on previous +patches, just indicate that in the patch. Note that it may take a while +for patches to be committed, and some patches may not be committed at +all. In either case, all sent patches are queued from the Matrix room into the +public patch directory, so they can be referenced easier +in the future. If you want to reference a submitted patch in a Matrix message +or email, it might be a good idea to link to it in the public patch directory. +
+
+The public patch directory works as follows: as soon as your patch is recieved,
+it will be downloaded and placed in the queue/
directory. Then,
+if your patch is accepted, it will be moved to the accepted/
+directory and then committed to the official CVS repository. If you patch is
+rejected for some reason, it will be moved to the rejected/
+directory. Regardless of the state of your patch, it will always be permalinked
+in the p/
directory.
+
+You're always welcome to inquire about rejected patches, and request they be +reviewed again, or you can use them as a starting point for future patches.