This commit is contained in:
Jordan Bancino 2022-07-29 15:29:39 -04:00
parent 81826ad2d2
commit 27acd6dc45

View file

@ -148,6 +148,7 @@ Submit code patches to the <b>Telodendria</b> project.
<ul> <ul>
<li><a href="#getting-the-code">Getting The Code</a></li> <li><a href="#getting-the-code">Getting The Code</a></li>
<li><a href="#code-style">Code Style</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> <li><a href="#submitting-patches">Submitting Patches</a></li>
</ul> </ul>
</li> </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, 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. just to make sure the spacing is consistent, if nothing else.
</p> </p>
<h4 id="the-build-script">The Build Script</h4>
<!-- describe recipes and the .env file -->
<h4 id="submitting-patches">Submitting Patches</h4> <h4 id="submitting-patches">Submitting Patches</h4>
<p> <p>
<b>Telodendria</b> aims at remaining as minimal as possible. This doesn't <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. 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 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 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> </p>
<div class="code"> <div class="code">
$ cvs diff -uNp &gt; your-changes.patch $ sh make.sh patch
</div> </div>
<p> <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> </p>
<div class="code"> <div class="code">
From: Jordan Bancino &lt;@jordan:bancino.net&gt; From: Jordan Bancino &lt;@jordan:bancino.net&gt;
Date: Fri Jul 29 03:21:21 PM EDT 2022
Subject: Document Patch Procedure Subject: Document Patch Procedure
Date: 2022-07-27
</div> </div>
<p> <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. description of the patch.
</p> </p>
<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>
<p> <p>
The public patch directory works as follows: as soon as your patch is recieved, 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>
<p> <p>
You're always welcome to inquire about rejected patches, and request they be You're always welcome to inquire about rejected patches, and request they be