Apply #12

site/index.html

@@ -148,6 +148,7 @@ Submit code patches to the <b>Telodendria</b> project.
 <ul>
 <li><a href="#getting-the-code">Getting The Code</a></li>
 <li><a href="#code-style">Code Style</a></li>
+<li><a href="#the-build-script">The Build Script</a></li>
 <li><a href="#submitting-patches">Submitting Patches</a></li>
 </ul>
 </li>
@@ -596,6 +597,8 @@ that I should run <code>indent(1)</code> on the code after applying it.
 I'll likely run my <code>indent(1)</code> on the code anyway though,
 just to make sure the spacing is consistent, if nothing else.
 </p>
+<h4 id="the-build-script">The Build Script</h4>
+<!-- describe recipes and the .env file -->
 <h4 id="submitting-patches">Submitting Patches</h4>
 <p>
 <b>Telodendria</b> 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
+have made your changes in your local copy of the code, just run the
-<code>cvs diff</code>:
+<code>patch</code> recipe:
 </p>
 <div class="code">
-$ cvs diff -uNp &gt; your-changes.patch
+$ sh make.sh patch
 </div>
 <p>
-At this point, it would be a good idea to open up your patch file in
+This will automatically generate the patch file from all your changes,
-your preferred editor and look it over to make sure everything looks
+and then open it in your default editor. You can set the
-good. While you have the file open, you should also add some
+<code>EDITOR</code> variable to your preferred editor if the default
-email-style headers to the top of your patch file, for quick
+doesn't work for you. Either set it in your environment via your
-identification:
+preferred means, or set it like this:
+</p>
+<div class="code">
+$ EDITOR=gedit sh make.sh patch
+</div>
+<p>
+You can also generate a patch for only certain files and directories.
+To do that, set <code>PATCH</code>, like this:
+</p>
+<div class="code">
+# Only write a patch for README.txt and the files in site/
+$ PATCH="README.txt site/" sh make.sh patch
+</div>
+<p>
+You can of course specify both <code>PATCH</code> and
+<code>EDITOR</code> at the same time, if you want. But at that point,
+it might make more sense to just set them in <code>.env</code> or in
+your system environment.
+</p>
+<p>
+As you'll notice, the top of the patch file should have some email-style
+headers that look like this:
 </p>
 <div class="code">
 From: Jordan Bancino &lt;@jordan:bancino.net&gt;
+Date: Fri Jul 29 03:21:21 PM EDT 2022
 Subject: Document Patch Procedure
-Date: 2022-07-27
 </div>
 <p>
-Obviously, set the actual values to your own information. <code>From</code>
+As much information as possible should be filled out for you, such as the
-should be your name and Matrix ID, and <code>Date</code> should be in the format
+date. An attempt to fill out the <code>From</code> header was also made,
-<code>%Y-%m-%d</code>. The <code>Subject</code> should very briefly
+but the information there can be made more accurate by setting
-describe what the patch is about. Below these headers, write a more in-depth
+<code>MXID</code> to your Matrix ID, and <code>DISPLAY_NAME</code> to your
+real name. The <code>Subject</code> should very briefly describe what
+the patch is about. Below these headers, write a more in-depth
 description of the patch.
 </p>
 <p>
@@ -670,12 +696,18 @@ or email, it might be a good idea to link to it in the public patch directory.
 </p>
 <p>
 The public patch directory works as follows: as soon as your patch is recieved,
-it will be downloaded and placed in the <code>queue/</code> directory. Then,
+it is downloaded and placed in the <code>ingress/</code> directory with the
-if your patch is accepted, it will be moved to the <code>accepted/</code>
+original name it was given. Eventually, it will be assigned an ID and moved
-directory and then committed to the official CVS repository. If you patch is
+to the <code>p/</code> directory. There is a permanent link that will
-rejected for some reason, it will be moved to the <code>rejected/</code>
+always reference your patch. Then, your patch is symlinked to the
-directory. Regardless of the state of your patch, it will always be permalinked
+<code>queue/</code> directory. I have a script that automatically ingresses
-in the <code>p/</code> directory.
+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
+<code>accepted/</code> 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 <code>rejected/</code> directory. Regardless of the state
+of your patch, it will always remain permalinked in the <code>p/</code>
+directory.
 </p>
 <p>
 You're always welcome to inquire about rejected patches, and request they be