1 # Contributing to librsync {#page_contributing}
3 Instructions and conventions
for people wanting to work on librsync. Please
4 consider these guidelines even
if you
're doing your own fork.
8 The prefered style for code is equivalent to using GNU indent with the
12 $ indent -linux -nut -i4 -ppi2 -l80 -lc80 -fc1 -fca -sob
15 The preferred style for non-docbook comments are as follows;
22 | reformated or reindented
25 /* Single line comment indented to match code indenting. */
27 /* Blank line delimited paragraph multi-line comments.
29 Without leading stars, or blank line comment delimiters. */
31 int a; /* code line comments */
34 The preferred style for docbook comments is javadoc with autobrief as
52 int a; /**< brief attribute description */
53 int b; /**< multiline attribute description
55 * With blank line delimited paragraphs.*/
58 There is a `make tidy` target that will use GNU indent to reformat all
59 code and non-docbook comments, doing some pre/post processing with sed
60 to handle some corner cases indent doesn't handle well.
62 There is also a `make tidyc` target that will reformat all code and
64 correctly reformat all docbook comments, equivalent to running tidyc
65 with the following arguments;
73 Fixes or improvements in pull requests are welcome. Please:
75 - [ ] Send small PRs that address one issues each.
77 - [ ] Update `NEWS.md` to say what you changed.
79 - [ ] Add a test as a
self-contained C file in `tests/` that passes or fails,
80 and is hooked into `CMakeLists.txt`.
82 - [ ] Keep the code style consistent with what
's already there, especially in
83 keeping symbols with an `rs_` prefix.
88 [NEWS.md](NEWS.md) contains a list of user-visible changes in the library between
89 releases version. This includes changes to the way it's packaged,
90 bug fixes, portability notes, changes to the API, and so on.
93 and update items under a
"Changes in X.Y.Z" heading at the top of
94 the file. Do
this as you go along, so that we don
't need to work
95 out what happened when it's time
for a release.
99 Please
try to update docs and tests in parallel with code changes.
103 If you are making a
new tarball release of librsync, follow
this checklist:
105 * NEWS.md - make sure the top
"Changes in X.Y.Z" is correct, and the date is
108 * `CMakeLists.txt` - version is correct.
110 * `librsync.spec` - make sure version and URL are right.
112 * Run `make all doc check` in a clean checkout of the release tag.
114 Test results
for builds of
public github branches are at