From 27acd6dc45c2add6f6d1d63a0f2a1520a22e542d Mon Sep 17 00:00:00 2001 From: Jordan Bancino Date: Fri, 29 Jul 2022 15:29:39 -0400 Subject: [PATCH] Apply #12 --- site/index.html | 70 +++++++++++++++++++++++++++++++++++-------------- 1 file changed, 51 insertions(+), 19 deletions(-) diff --git a/site/index.html b/site/index.html index abe0f0c..eb9c2cd 100644 --- a/site/index.html +++ b/site/index.html @@ -148,6 +148,7 @@ Submit code patches to the Telodendria project. @@ -596,6 +597,8 @@ that I should run indent(1) on the code after applying it. I'll likely run my indent(1) on the code anyway though, just to make sure the spacing is consistent, if nothing else.

+

The Build Script

+

Submitting Patches

Telodendria aims at remaining as minimal as possible. This doesn't @@ -611,29 +614,52 @@ 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: +have made your changes in your local copy of the code, just run the +patch recipe:

-$ cvs diff -uNp > your-changes.patch +$ sh make.sh patch

-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: +This will automatically generate the patch file from all your changes, +and then open it in your default editor. You can set the +EDITOR variable to your preferred editor if the default +doesn't work for you. Either set it in your environment via your +preferred means, or set it like this: +

+
+$ EDITOR=gedit sh make.sh patch +
+

+You can also generate a patch for only certain files and directories. +To do that, set PATCH, like this: +

+
+# Only write a patch for README.txt and the files in site/ +$ PATCH="README.txt site/" sh make.sh patch +
+

+You can of course specify both PATCH and +EDITOR at the same time, if you want. But at that point, +it might make more sense to just set them in .env or in +your system environment. +

+

+As you'll notice, the top of the patch file should have some email-style +headers that look like this:

From: Jordan Bancino <@jordan:bancino.net> +Date: Fri Jul 29 03:21:21 PM EDT 2022 Subject: Document Patch Procedure -Date: 2022-07-27

-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 +As much information as possible should be filled out for you, such as the +date. An attempt to fill out the From header was also made, +but the information there can be made more accurate by setting +MXID to your Matrix ID, and DISPLAY_NAME to your +real name. The Subject should very briefly describe what +the patch is about. Below these headers, write a more in-depth description of the patch.

@@ -670,12 +696,18 @@ 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. +it is downloaded and placed in the ingress/ directory with the +original name it was given. Eventually, it will be assigned an ID and moved +to the p/ directory. There is a permanent link that will +always reference your patch. Then, your patch is symlinked to the +queue/ directory. I have a script that automatically ingresses +patches and queues them for me, and I'll use this to review patches. +If your patch is accepted, the queue symlink will be moved to the +accepted/ directory and the patch is committed to the official +CVS repository. If you patch is rejected for some reason, its symlink will +be moved to the rejected/ directory. Regardless of the state +of your patch, it will always remain permalinked in the p/ +directory.

You're always welcome to inquire about rejected patches, and request they be