forked from lda/telodendria
Apply #12
This commit is contained in:
parent
81826ad2d2
commit
27acd6dc45
1 changed files with 51 additions and 19 deletions
|
@ -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 > 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 <@jordan:bancino.net>
|
From: Jordan Bancino <@jordan:bancino.net>
|
||||||
|
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
|
||||||
|
|
Loading…
Reference in a new issue