18.4 KB
Newer Older
Tomek Mrugalski's avatar
Tomek Mrugalski committed
1 2
# Kea Contributor's Guide

3 4
So you found a bug in Kea or plan to develop an extension and want to send us a patch? Great! This
page will explain how to contribute your changes smoothly.
Tomek Mrugalski's avatar
Tomek Mrugalski committed

Tomek Mrugalski's avatar
Tomek Mrugalski committed
6 7 8
Here's a quick list of how to contribute a patch:

1. **create account** on [gitlab](
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
2. **open an issue** in [Kea project](, make sure
   it describes what you want to fix and **why**
3. **ask someone from the ISC team to give you permission to fork Kea** (ask @tomek, @vicky, @ondrej
   or @godfryd or basically anyone from the Kea dev team)
4. **fork Kea code**: go to Kea project page, click [Fork button](
   If you can't, you didn't complete step 3.
5. **Implement your fix or feature, push code** to your repo. Make sure it compiles, has unit-tests,
   is documented and does what it's supposed to do.
6. **Open Merge Request**: go to Kea project [merge requests page](,
   click [New merge request]( If you
   don't see the button, you didn't complete step 3.
7. **Participate in the code review**: Once you submit the MR, someone from ISC will eventually get
   to the issue and will review your code. Please make sure you respond to comments. It's likely
   you'll be asked to update the code.

Tomek Mrugalski's avatar
Tomek Mrugalski committed
For a much more detailed description with details, see the text below.
Tomek Mrugalski's avatar
Tomek Mrugalski committed
25 26 27

## Writing a patch

28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
Before you start working on a patch or a new feature, it is a good idea to discuss it first with Kea
developers.  You can post your questions to the [kea-dev](
or [kea-users]( mailing lists. The kea-users is
intended for users who are not interested in the internal workings or development details of Kea: it
is OK to ask for feedback regarding new design or the best proposed solution to a certain
problem. This is the best place to get user's feedback. The internal details, questions about the
code and its internals are better asked on kea-dev.

OK, so you have written a patch? Great! Before you submit it, make sure that your code
compiles. This may seem obvious, but there's more to it. You have surely checked that it compiles on
your system, but Kea is a portable software. Besides Linux, it is compiled and used on relatively
uncommon systems like OpenBSD. Will your code compile and work there? What about endianness? It is
likely that you used a regular x86 architecture machine to write your patch, but the software is
expected to run on many other architectures. You may take a look at [system specific build
notes]( For a complete list of systems we build on, you may
take a look at the [Jenkins build farm](

45 46
### Coding guidelines

47 48 49 50 51 52
Does your patch conform to [Kea coding
guidelines](  You can submit a
patch that does not adhere to them, but that will reduce its chances of being accepted.  If the
deviations are minor, one of the Kea engineers who does the review will likely fix the issues.
However, if there are lots of issues, the reviewer may simply reject the patch and ask you to fix it
before re-submitting.
Tomek Mrugalski's avatar
Tomek Mrugalski committed

54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86
Placed in the root of the repository are files that formally describe the coding
guidelines above as close as possible. They are `.clang-format` and
`.uncrustify.cfg` used by `clang-format` and `uncrustify` respectively. If you
want to format code automatically, you will need to have at least one of these
tools installed. Since by default, these tools look for the closest style file
located in one of the parent directories or, otherwise, in a default location,
there are a a couple of helpful scripts i.e. `./tools/` and
`./tools/` to assure you that the Kea-owned file is used. They
accept any number of customized parameters that would be passed to the
underlying tool followed by any number of files and/or directories. Passing
directories will have all non-generated C++ files under it formatted.

IDEs often offer support for code formatting tools. For example, in Visual
Studio Code, you may install `Clang-Format` and `crustless` through the Command
Palette (`Ctrl + Shift + P` by default), `Extensions: Install Extensions`.
Then open a source file, select code that you want formatted, open the Command
Palette, and choose `Format Selection`. You might go through an onboarding step
where you choose the formatter in the case you have both installed, but that
should be it.

When using these tools, it can be tempting to format entire files at once. In
the interest of preserving git history as much as possible, it is recommended
that you only format code that you have added or changed. This is much easier
done in an IDE, but as long as the tool supports it, it can be done using the
provided scripts e.g.:

./tools/ --lines=13:37 ./src/lib/dhcpsrv/

Uncrustify does not seem to have a line-range-limiting option at the time of
this writing.

Tomek Mrugalski's avatar
Tomek Mrugalski committed
87 88
## Running unit-tests

89 90 91 92 93 94 95 96 97 98 99 100 101 102
One of the ground rules in Kea development is that every piece of code has to be tested. We now have
an extensive set of unit-tests for almost every line of code. Even if you are fixing something
small, like a single line fix, you are encouraged to write unit-tests for that change. That is even
more true for new code: if you write a new function, method or a class, you definitely should write
unit-tests for it.

To ensure that everything is tested, ISC uses a development method called [Test Driven Development
(TDD)]( In TDD, a feature is developed
alongside the tests, preferably with the tests being written first. In detail, a test is written for
a small piece of functionality and run against the existing code. (In the case where the test is a
unit test for a function, it would be run against an empty (unimplemented) function.) The test
should fail.  A minimal amount of code is then written, just enough to get the test to pass. Then
the process is repeated for the next small piece of functionality. This continues until all the
functionality has been implemented.
Tomek Mrugalski's avatar
Tomek Mrugalski committed
103 104 105

This approach has two advantages:

106 107 108 109
 - By writing a test first and then only enough code to pass the test, that code is fully tested. By
   repeating this process until the feature is fully implemented, all the code gets test
   coverage. You avoid the situation where not enough tests have been written to check all the
Tomek Mrugalski's avatar
Tomek Mrugalski committed

111 112 113
 - By running the test before the code implementing the function is written and observing the test
   fail, you can detect the situation where a bug in the test code will cause it to pass regardless
   of the code being tested.
Tomek Mrugalski's avatar
Tomek Mrugalski committed

115 116 117 118 119 120 121 122
Initially, some people unfamiliar with that approach react with "but my change is simple and I
tested that it works". That approach is both insufficient and short-sighted. It is insufficient,
because manual testing is by definition laborious and can't really be done on the multitude of
systems we run Kea on. It is short-sighted, because even with your best intentions you will not be
able to dedicate any significant amount of time for repeated testing of your improved code. The old
ISC DHCP has two decades of history behind it and we hope to make Kea last similar time span. Over
such long periods, code tends to be refactored several times. The change you made may be affected by
some other change or by the code that hasn't been written yet.
Tomek Mrugalski's avatar
Tomek Mrugalski committed

124 125 126 127 128 129 130
See Building Kea with Unit Tests for instructions on how to run unit-tests. If you happen to touch
any database related code, make sure you compile your code with –with-mysql, –with-pgsql and/or
–with-cql as needed. For example, if you change something substantial, make sure the other
compilation options still work.

If you happen to add new files or have modified any files, it is also a good idea to
check if you haven't broken the distribution process:
Tomek Mrugalski's avatar
Tomek Mrugalski committed
131 132 133 134 135

make distcheck

136 137 138 139 140 141 142 143
There are other useful switches which can be passed to configure. It is always a good idea to use
`–enable-logger-checks`, which does sanity checks on logger parameters. Use `–-enable-debug` to
enable various additional consistency checks that reduce performance but help during development. If
you happen to modify anything in the documentation, use `–-enable-generate-docs`. If you are
modifying DHCP code, you are likely to be interested in enabling a non-default database backends for
DHCP. Note that if the backend is not enabled, the database-specific unit-tests are skipped.  To
enable the MySQL backend, use the switch `–with-mysql`; for PostgreSQL, use `–with-pgsql` and for
Cassandra use `--with-cql`. A complete list of all switches can be obtained with the command:
Tomek Mrugalski's avatar
Tomek Mrugalski committed
144 145 146 147 148

./configure --help

Tomek Mrugalski's avatar
Tomek Mrugalski committed
## Submitting Merge Request (also known as sending your patch the right way)
Tomek Mrugalski's avatar
Tomek Mrugalski committed

151 152 153 154 155
The first step in writing the patch or new feature should be to get the source code from our Git
repository.  The procedure is very easy and is [explained
here](  While it is possible
to provide a patch against the latest stable release, it makes the review process much easier if it
is for latest code from the Git master branch.
Tomek Mrugalski's avatar
Tomek Mrugalski committed

157 158 159
ISC uses [gitlab]( to manage its source code. While we also maintain presence
on [github](, the process of syncing gitlab to github is mostly
automated and Kea devs rarely look at github.
Tomek Mrugalski's avatar
Tomek Mrugalski committed

161 162 163 164 165 166 167
ISC's gitlab has been a target for spammers in the past, so it is now set up defensively. In
particular, new users can't fork the code on their own and it requires someone from ISC to manually
grant the ability to fork projects.  Fortunately, this is easy to do and we glady do this for anyone
who asks and provides a good reason. "I'd like to fix bug X or develop feature Y" is an excellent
reason. The best place for asking is either kea-dev or asking in a comment in your issue. Make sure
you put a name tag (@tomek, @godfryd, @vicky or @ondrej). When you write a comment in an issue or
merge request and add a name tag on it, the user is automatically notified.
Tomek Mrugalski's avatar
Tomek Mrugalski committed

169 170 171
Once you fork the Kea code in gitlab, you have your own copy and you can commit your changes there
and push them to your copy of Kea repo. Once you feel that your patch is ready, go to Kea project
and [submit a Merge Request](
Tomek Mrugalski's avatar
Tomek Mrugalski committed

173 174 175
If you can't access this link or don't see New Merge Request button on the [merge requests
page](, please ask on kea-dev and someone
will help you out.
Tomek Mrugalski's avatar
Tomek Mrugalski committed
176 177 178

## Send Pull Request on github

179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201
If you can't send the patch on gitlab, the next best preferred way is to send pull request (PR) on

This is almost as good as sending MR on gitlab. The downside is that Kea devs don't look at github
too frequently, so it may be a while before we notice it. And when we do, the chances are we will be
busy with other things. With gitlab, your MR will stare at us the whole time, so we'll get round to
it much quicker. But we understand that there are some cases where people may prefer github over

See the excellent documentation on github:
for details. In essence, you need github account (spam/hassle free, takes one minute to set
up). Then you can fork the Kea repository, commit changes to your repo and ask us to pull your
changes into official Kea repository. This has a number of advantages. First, it is made against a
specific code version, which can be easily checked with git log command. Second, this request pops
up instantly on our list of open pull requests and will stay there. The third benefit is that the
pull request mechanism is very flexible. Kea engineers (and other users, too) can comment on it,
attach links, mention other users etc. You as a submitter can augment the patch by committing extra
changes to your repository. Those extra commits will appear instantly in the pull request. This is
really useful during the review. Finally, Kea developers can better assess all open pull requests
and add labels to them, such as "enhancement", "bug", or "unit-tests missing". This makes our life
easier. Oh, and your commits will later be shown as yours in github history. If you care for that
kind of things, once the patch is merged, you'll be automatically listed as contributor and Kea will
be listed as project you have contributed to.
Tomek Mrugalski's avatar
Tomek Mrugalski committed

## If you really can't do MR on gitlab or PR on github...

205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240
Well, you are out of luck. There are other ways, but those are really awkward and the chances of
your patch being ignored are really high. Anyway, here they are:

- [create an issue in the Kea Gitlab]( and attach
  your patch to it. Sending a patch has a number of disadvantages. First, if you don't specify the
  base version against which it was created, one of Kea developers will have to guess that or go
  through a series of trials and errors to find that out. If the code doesn't compile, the reviewer
  will not know if the patch is broken or maybe it was applied to incorrect base code. Another
  frequent problem is that it may be possible that the patch didn't include any new files you have
  added.  If we happen to have any comments that you as submitter are expected to address (and in
  the overwhelming majority of cases, we have), you will be asked to send an updated patch. It is
  not uncommon to see several rounds of such reviews, so this can get very complicated very
  quickly. Please don't add your issue to any milestone. Kea team has a process of going through
  issues unassigned to any milestone. Kea developers review new issues once a week and assign them
  to specific milestones. Please do not add issues to working milestones directly. Having an issue
  in gitlab ensures that the patch will never be forgotten and it will show up on our gitlab
  reports. It's not required, but much appreciated if you send a short note to the kea-dev mailing
  list explaining what you did with the code and announce the issue number.

- Send a patch to the kea-dev list. This is the third preferred method, if you can't or don't want
  to use gitlab and github. If you send a patch to a mailing list in a wrong time, e.g. shortly
  before a release, Kea developers may miss it or perhaps they will see it and then forget about
  it. Nevertheless, it is still doable and we successfully accepted patches that way. It just takes
  more time from everyone involved, so it's a slower process in general.

- Send a tarball with your modified code. This is really the worst way one can contribute a
  patch. It has a number of disadvantages. In particular, someone will need to find out which
  version the code was based on and generate the patch. It's not rocket science, but it may be a
  very mundane thing to do if the Kea developer does not know the version in advance. The mailing
  list has a limit on the message size (for good reasons), so you'll likely need to upload it
  somewhere first. Kea developers often don't pick up new issues instantly, so it may have to wait
  weeks before the tarball is looked at. The tarball does not benefit from most of the advantages
  mentioned for github, like the ability to easily update the code, have a meaningful discussion or
  see what the exact scope of changes are. Nevertheless, if we given a choice of getting a tarball
  or not getting a patch at all, we prefer tarballs. Just keep in mind that processing a tarball is
  really cumbersome for Kea developers, so it may take significantly longer than other ways.
Tomek Mrugalski's avatar
Tomek Mrugalski committed
241 242 243

## Going through a review

244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276
Once you make your patch available using one of the ways above, the action is on one of the Kea
developers. We need an issue. While we can create it on our own, we prefer the original submitter
fill them in as he or she has the best understanding of the purpose of the change and may have any
extra information about OS, version, why it was done this specific way etc. If there is no MR and no
gitlab issue, you risk the issue not showing up on ISC radars. Depending on the subjective
importance and urgency as perceived by the ISC engineer, the issue or PR will be assigned to one of
the milestones.

Sooner or later, one of Kea developers will do the review. Here's the tricky part. One of Kea
developers will review your patch, but it may not happen immediately. Unfortunately, developers are
usually working under a tight schedule, so any extra unplanned review work may take a while. Having
said that, we value external contributions very much and will do whatever we can to review patches
in a timely manner. Don't get discouraged if your patch is not accepted after first review. To keep
the code quality high, we use the same review processes for external patches as we do for internal
code. It may take some cycles of review/updated patch submissions before the code is finally
accepted. The nature of the review process is that it emphasizes areas that need improvement. If you
are not used to the review process, you may get the impression that the feedback is negative.  It is
not: even the Kea developers seldom see reviews that say "All OK please merge".

Once the process is almost complete, the developer will likely ask you how you would like to be
credited.  The typical answers are by first and last name, by nickname, by company name or
anonymously. Typically we will add a note to the ChangeLog and also set you as the author of the
commit applying the patch and update the contributors section in the AUTHORS file. If the
contributed feature is big or critical for whatever reason, it may also be mentioned in release

Sadly, we sometimes see patches that are submitted and then the submitter never responds to our
comments or requests for an updated patch. Depending on the nature of the patch, we may either fix
the outstanding issues on our own and get another Kea developer to review them or the issue may end
up in our Outstanding milestone. When a new release is started, we go through the issues in
Outstanding, select a small number of them and move them to whatever the current milestone is. Keep
that in mind if you plan to submit a patch and forget about it. We may accept it eventually, but
it's much, much faster process if you participate in it.

#### Thank you for contributing your time and experience to the Kea project!