plate/telodendria
1
0
Fork 0
forked from lda/telodendria
Code Pull requests Activity Actions

Apply #12

Browse source
This commit is contained in:
Jordan Bancino 2022-07-29 15:29:39 -04:00
parent 81826ad2d2
commit 27acd6dc45
1 changed files with 51 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

70
site/index.html
View file

@ -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
<code>cvs diff</code>:
have made your changes in your local copy of the code, just run the
<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
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
<code>EDITOR</code> 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:
</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>
should be your name and Matrix ID, and <code>Date</code> should be in the format
<code>%Y-%m-%d</code>. The <code>Subject</code> 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 <code>From</code> header was also made,
but the information there can be made more accurate by setting
<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,
if your patch is accepted, it will be moved to the <code>accepted/</code>
directory and then committed to the official CVS repository. If you patch is
rejected for some reason, it will be moved to the <code>rejected/</code>
directory. Regardless of the state of your patch, it will always be permalinked
in the <code>p/</code> directory.
it is downloaded and placed in the <code>ingress/</code> directory with the
original name it was given. Eventually, it will be assigned an ID and moved
to the <code>p/</code> directory. There is a permanent link that will
always reference your patch. Then, your patch is symlinked to the
<code>queue/</code> 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
<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