Project

General

Profile

DevelopersProcess » History » Version 23

Aaron P, 01/25/2017 04:08 PM
Added config for BCCing patch emails. Also highlighted a couple of things that caused me to read properly after skimming a couple of times and looking foolish.

1 1 Dan Smith
h1. CHIRP Development Process
2 6 Dan Smith
3 5 Dan Smith
{{>toc}}
4 6 Dan Smith
5 1 Dan Smith
h2. Mercurial Configuration
6
7 15 Robert Terzi
Make sure that your mercurial tool is configured properly for CHIRP. This means having the correct username and email address specified, as well as the MQ extension enabled (for most cases). You can do this in your global mercurial configuration file, or in the one in the repository you're working on, which is @.hg/hgrc@ in the top level chirp.hg directory. You may also want to ensure that it has the patchbomb configuration enabled, which allows easy emailing out of mercurial itself. You probably want the following lines in your config file:
8 1 Dan Smith
9 23 Aaron P
h3. @chirp.hg/.hg/hgrc@
10
11 1 Dan Smith
<pre>
12
[ui]
13
username = Joe Bob <joebob@gmail.com>
14
[extensions]
15
hgext.mq=
16
hgext.patchbomb=
17 7 Dan Smith
18 1 Dan Smith
[email]
19
from = Joe Bob <joebob@gmail.com>
20
method = smtp
21 16 Tom Hayward
to = chirp_devel@intrepid.danplanet.com
22 23 Aaron P
# Add a bcc if you want a copy of the email
23
# bcc = Joe Bob <joebob@gmail.com>
24 1 Dan Smith
25
[smtp]
26
host = smtp.gmail.com
27 16 Tom Hayward
port = 587
28
tls = True
29 1 Dan Smith
</pre>
30
31 13 Dan Smith
h2. Getting the code
32
33
<pre>
34
hg clone http://d-rats.com/hg/chirp.hg
35
cd chirp.hg
36
</pre>
37
38 3 Dan Smith
h2. Bug Tracking
39
40
All changes should have a bug created on the tracker before submission. The server hosting the repository will not allow changesets to be pushed that do not contain a bug number (see below). It is perfectly reasonable to create a bug, assign it to yourself, and then close it before sending the patch.
41
42 1 Dan Smith
h2. Submitting a patch
43
44 2 Dan Smith
Changes to CHIRP are welcome, but they should be in the correct format, and sent as a patch to the mailing list. The correct way to do this is to clone the upstream repository, make your changes there, and then soft-commit them as MQ patches to the tree. The following assumes you have cloned the repository and are in the resulting directory.
45
46 14 Robert Terzi
You must include an Issue Number (#123) in the first line of the commit message to tie each patch to an issue for tracking purposes.
47
48 2 Dan Smith
h3. Making a change
49
50
Edit one of the files to make a change. For this example, I'll use @chirp/ic2820.py@. Assuming I have made a change, the following commands help me see what has been done:
51
52
<pre>
53
% hg status -mar
54
M chirp/ic2820.py
55
% hg diff
56
diff -r a132c837fd25 chirp/ic2820.py
57
--- a/chirp/ic2820.py   Mon Dec 24 08:17:19 2012 -0800
58
+++ b/chirp/ic2820.py   Mon Dec 24 08:56:29 2012 -0800
59
@@ -16,6 +16,8 @@
60
 from chirp import chirp_common, icf, util, directory
61
 from chirp import bitwise
62
 
63
+# Just added a comment
64
+
65
 MEM_FORMAT = """
66
 struct {
67
   u32  freq;
68
</pre>
69
70
The first command shows me that @chirp/ic2820.py@ has been modified, and the second shows me the actual changes that have been made.
71
72
h3. Soft-committing a Change
73
74 11 Tom Hayward
You can commit a change directly to your tree, but it becomes a little more complicated to make changes to it if necessary, and it creates a fork when the change is actually accepted upstream. An easy way to mitigate this is to soft-commit your changes as MQ patches. Assuming you have made the change above, the following example shows the process for committing that into a patch:
75 2 Dan Smith
76
<pre>
77 11 Tom Hayward
% hg qnew -ef mypatch     # Here an editor will open to compose a commit message
78 2 Dan Smith
% hg qapplied             # This shows that the patch is now applied
79 11 Tom Hayward
mypatch
80 2 Dan Smith
</pre>
81
82 11 Tom Hayward
This example takes the changes I made above, and commits them into a new patch called @mypatch@. I can now look at the patch in its entirety, as well as add or remove it from my local tree:
83 2 Dan Smith
84 11 Tom Hayward
| Command | Description |
85
| @hg export tip@           | This will show me the whole patch, with the commit message |
86 14 Robert Terzi
| @hg export tip > mypatch.patch@ | This will save the patch, including commit message, to mypatch.patch. You can then attach this file to an email to chirp_devel for submission. |
87 15 Robert Terzi
| @hg email tip@   | If hg is correctly configured with your email address, name and SMTP server, it will automatically generate an email with the patch included. It will prompt you for the To: address. |
88 14 Robert Terzi
89 15 Robert Terzi
90 14 Robert Terzi
See "Sending a Change" below.
91
92
93
h3. Working with Patches (mq mercurial extension)
94
95
The following commands demonstrate how the mq extension to hg can be used for managing patches.
96
97
| Command | Description |
98
| @hg export tip@           | This will show me the whole patch, with the commit message |
99 11 Tom Hayward
| @hg export tip > mypatch.patch@ | This will save the patch, including commit message, to mypatch.patch. You can then attach this file to an email for submission. |
100
| @hg qpop@                 | Remove it from the tree |
101
| @hg qapplied@             | This shows that no patches are applied |
102
| @hg qunapplied
103
mypatch@                   | This shows that our patch is not applied |
104
| @hg qpush@                | This adds the patch back to the tree |
105
| @hg qapplied
106
mypatch@                   | This shows that our patch is applied |
107
| @hg qpop@                 | This removes it again |
108
| @hg qdel mypatch@         | This deletes it permanently |
109 20 Aaron P
| @hg strip --keep --rev .@  | Made an actual commit instead of using mq? This will unstage the last commit, similar to git reset --soft HEAD~1 |
110 2 Dan Smith
111 19 Aaron P
If this tool intrigues you, you can learn how to use it here: https://www.mercurial-scm.org/wiki/MqTutorial
112 12 Tom Hayward
113 4 Dan Smith
h3. Testing
114
115
CHIRP has a modest test suite used to validate driver behavior in the @tests/@ directory. Before submitting a patch, please ensure that all the tests run and pass (or at least pass as well as before you made the change). To run the whole set, do this:
116
117
<pre>
118
% cd tests
119
% ./run_tests
120
</pre>
121
122 8 Dan Smith
Note that on Windows, you probably want to run the script like this:
123
124
<pre>
125 9 Dan Smith
C:\Users\Foo\chirp.hg\tests> python run_tests
126 8 Dan Smith
</pre>
127
128 4 Dan Smith
To run just a single driver's tests:
129
130
<pre>
131
% ./run_tests -d Icom_IC-2820H
132
</pre>
133
134
To run just a specific test:
135
136
<pre>
137
% ./run_tests -t Edges
138
</pre>
139
140 18 Brian Dickman
If you are adding a new driver, you will need to add an image to the @tests/images/@ directory which is correctly named for your model. These do not communicate well in patch form, so just attach your test image to the issue on the tracker and send a heads-up to the devel list so it can be snagged into the repo.
141 4 Dan Smith
142
Note: Please make sure that all the tests run, not just the one that affects your driver. Several of the drivers play off each other and sometimes changes to one will break another.
143 1 Dan Smith
144 15 Robert Terzi
h3. Sending a change
145 2 Dan Smith
146
There are two ways to do this. First, you can export the patch to a text file and email it to the list with your normal mailer. This is how:
147
148
<pre>
149
% hg export tip > add_comment.patch
150
</pre>
151
152
You can also configure the tool to email it directly, in which case you need only do:
153
154
<pre>
155
% hg email tip
156
</pre>
157 3 Dan Smith
158
You will be prompted for the destination address.
159
160 22 Dan Smith
h2. Setting up *GMail* for patchbomb email
161 17 Brian Dickman
162 23 Aaron P
h3. Without two factor identification
163
164 21 Dan Smith
If you have a gmail account, setup the port and TLS enable as shown above. You can use your regular gmail username and password if you have not enabled two-factor authentication.
165 23 Aaron P
166
h3. With two factor identification
167 17 Brian Dickman
168 22 Dan Smith
If it bugs you to have your gmail password in a text file (and it should), you can enroll in two-factor auth with google, but be aware that it will affect the usage of your account. You can enroll here:
169 17 Brian Dickman
170
https://myaccount.google.com/security/signinoptions/two-step-verification/enroll-welcome
171
172 21 Dan Smith
With TFA enabled, you can add app-specific passwords, like one for mercurial:
173 17 Brian Dickman
174
https://security.google.com/settings/security/apppasswords
175
176
With these steps complete, add the app-specific password to your hgrc, and you should be all set.
177
178 3 Dan Smith
h2. Patch Guidelines
179
180 1 Dan Smith
h3. The Commit Message
181 3 Dan Smith
182 14 Robert Terzi
The commit message should have a first line that stands on its own and describes the patch briefly. If it pertains to a specific driver, put that driver's short name in brackets at the beginning. An issue number from the issue tracking system must be included to tie the submitted patch to an open issue. For example:
183 3 Dan Smith
184
<pre>
185 14 Robert Terzi
[uv5r] Add support for firmware >= 291 Fixes #123
186 3 Dan Smith
</pre>
187
188
After the first line, more descriptive text may be added (and is appreciated) about what and why the change is being made. At the end, you must include a bug number in the format @#XXX@. This lets the system correlate changes to bugs, which helps during release time.
189
190
h3. Scope
191
192
Guidelines:
193
194
 * Patches should be small and concise. Try to keep a single standing change to a single patch.
195
 * Don't fix several bugs in a single patch, unless there is a technical reason to do so.
196
 * Don't fix, cleanup, or change random whitespace in the patch unless that is the sole purpose of the patch.