1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
Here are some rules for hacking libunicode. They are fairly simple.
Please follow them.
* libunicode follows the GNU Coding Standards.
Write ISO C.
Use the GNU formatting style.
Write portable code.
Always write ChangeLog entries according to the GNU rules.
I prefer the use of Perl or a portable shell script for any charset
code generator. Don't write the generator is some weirdly uncommon
language.
* Always compile your changes before checking them in.
On reasonable systems, libunicode should compile without warnings
using "-W -Wall -Wno-unused".
On losing systems like SunOS, you have to be more careful. Try to
avoid developing on these systems.
No checkin should cause test regressions.
Run "make check" before checkin.
(One exception to this: adding a new test to point out a failure without
fixing the bug is acceptable.)
* If you add a new charset transformation, and any part of the code
for the transform is generated automatically, you *must* document
how the transformation was done, where you got the tables, and how to
rebuild the auto-generated code. This is *vitally* important for
several reasons:
1. If we discover a bug in the transformation tables, we need to be
able to rebuild from the fixed table.
2. If we want to change the transform's implementation in
libunicode, we need to be able to change the code generator. This
implies that the code generator must also be checked in.
3. We need to be able to do independent checks on the legality of
using the charset tables you use. (A political and not a technical
requirement.)
* You get major bonus points, and my undying gratitude, for adding new
tests. Regression tests for simple bug fixes ought to be mandatory,
but for now they are not.
* Add yourself to the THANKS file. This is kept in naive alphabetical
order -- just sort the lines of the file.
* Since we are still pre-1.0, feel free to do prereleases whenever it
is convenient. The rules for doing a release are very simple:
* Odd numbers (0.3, 0.5) are for cvs only.
* Before a release, increase the version number to an even number.
* Update the NEWS file
* Check in the change (with ChangeLog entry, of course)
* Run "make all"
* Run "make cvs-dist"
* If this fails you will have to do some work by hand :-(
* If it succeeds, put the new .tar.gz up for ftp
Thanks for your cooperation and your contribution to libunicode. If
you find these rules unreasonable, feel free to contact me to discuss
it.
Tom Tromey <tromey@cygnus.com>
August 6, 1999
|
