mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-31 05:55:28 +00:00
Code Issues Releases Wiki Activity

[#633] Contributors guide wrapped

Browse Source 
- should be readable as a plain text
This commit is contained in:
Tomek Mrugalski
2019-05-27 19:17:16 +02:00
parent 1bfc766d41
commit c71cacb01b
1 changed files with 194 additions and 140 deletions
Download Patch File Download Diff File Expand all files Collapse all files

332
contributors-guide.md
View File

@@ -1,89 +1,111 @@
# Kea Contributor's Guide # Kea Contributor's Guide
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. 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.
Here's a quick list of how to contribute a patch: Here's a quick list of how to contribute a patch:
1. **create account** on [gitlab](https://gitlab.isc.org) 1. **create account** on [gitlab](https://gitlab.isc.org)
2. **open an issue** in [Kea project](https://gitlab.isc.org/isc-projects/kea/issues/new), make sure it describes what you want to fix and **why** 2. **open an issue** in [Kea project](https://gitlab.isc.org/isc-projects/kea/issues/new), make sure
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) it describes what you want to fix and **why**
4. **fork Kea code**: go to Kea project page, click [Fork button](https://gitlab.isc.org/isc-projects/kea/forks/new). If you can't, you didn't complete step 3. 3. **ask someone from the ISC team to give you permission to fork Kea** (ask @tomek, @vicky, @ondrej
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. or @godfryd or basically anyone from the Kea dev team)
6. **Open Merge Request**: go to Kea project [merge requests page](https://gitlab.isc.org/isc-projects/kea/merge_requests), click [New merge request](https://gitlab.isc.org/isc-projects/kea/merge_requests/new). If you don't see the button, you didn't complete step 3. 4. **fork Kea code**: go to Kea project page, click [Fork button](https://gitlab.isc.org/isc-projects/kea/forks/new).
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. 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](https://gitlab.isc.org/isc-projects/kea/merge_requests),
click [New merge request](https://gitlab.isc.org/isc-projects/kea/merge_requests/new). 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.
For a much more detailed description with details, see the text below. For a much more detailed description with details, see the text below.
## Writing a patch ## Writing a patch
Before you start working on a patch or a new feature, it is a good idea to discuss it first with Kea developers. Before you start working on a patch or a new feature, it is a good idea to discuss it first with Kea
You can post your questions to the [kea-dev](https://lists.isc.org/mailman/listinfo/kea-dev) or developers. You can post your questions to the [kea-dev](https://lists.isc.org/mailman/listinfo/kea-dev)
[kea-users](https://lists.isc.org/mailman/listinfo/kea-users) mailing lists. The kea-users is intended for users or [kea-users](https://lists.isc.org/mailman/listinfo/kea-users) mailing lists. The kea-users is
who are not interested in the internal workings or development details of Kea: it is OK to ask for feedback intended for users who are not interested in the internal workings or development details of Kea: it
regarding new design or the best proposed solution to a certain problem. This is the best place to get user's is OK to ask for feedback regarding new design or the best proposed solution to a certain
feedback. The internal details, questions about the code and its internals are better asked on kea-dev. 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 OK, so you have written a patch? Great! Before you submit it, make sure that your code
seem obvious, but there's more to it. You have surely checked that it compiles on your system, but Kea is compiles. This may seem obvious, but there's more to it. You have surely checked that it compiles on
a portable software. Besides Linux, it is compiled and used on relatively uncommon systems like OpenBSD. Will your system, but Kea is a portable software. Besides Linux, it is compiled and used on relatively
your code compile and work there? What about endianness? It is likely that you used a regular x86 architecture uncommon systems like OpenBSD. Will your code compile and work there? What about endianness? It is
machine to write your patch, but the software is expected to run on many other architectures. You may take likely that you used a regular x86 architecture machine to write your patch, but the software is
a look at [system specific build notes](https://kb.isc.org/docs/installing-kea). For a complete list of expected to run on many other architectures. You may take a look at [system specific build
systems we build on, you may take a look at the [Jenkins build farm](https://jenkins.isc.org/). notes](https://kb.isc.org/docs/installing-kea). For a complete list of systems we build on, you may
take a look at the [Jenkins build farm](https://jenkins.isc.org/).
Does your patch conform to [Kea coding guidelines](https://gitlab.isc.org/isc-projects/kea/wikis/coding-guidelines)? Does your patch conform to [Kea coding
You can submit a patch that does not adhere to them, but that will reduce its chances of being accepted. guidelines](https://gitlab.isc.org/isc-projects/kea/wikis/coding-guidelines)? You can submit a
If the deviations are minor, one of the Kea engineers who does the review will likely fix the issues. patch that does not adhere to them, but that will reduce its chances of being accepted. If the
However, if there are lots of issues, the reviewer may simply reject the patch and ask you to fix it before re-submitting. 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.
## Running unit-tests ## Running unit-tests
One of the ground rules in Kea development is that every piece of code has to be tested. We now have an One of the ground rules in Kea development is that every piece of code has to be tested. We now have
extensive set of unit-tests for almost every line of code. Even if you are fixing something small, like a an extensive set of unit-tests for almost every line of code. Even if you are fixing something
single line fix, you are encouraged to write unit-tests for that change. That is even more true for new code: small, like a single line fix, you are encouraged to write unit-tests for that change. That is even
if you write a new function, method or a class, you definitely should write unit-tests for it. 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)](https://en.wikipedia.org/wiki/Test-driven_development). In To ensure that everything is tested, ISC uses a development method called [Test Driven Development
TDD, a feature is developed alongside the tests, preferably with the tests being written first. In detail, a test is (TDD)](https://en.wikipedia.org/wiki/Test-driven_development). In TDD, a feature is developed
written for a small piece of functionality and run against the existing code. (In the case where the test is alongside the tests, preferably with the tests being written first. In detail, a test is written for
a unit test for a function, it would be run against an empty (unimplemented) function.) The test should fail. a small piece of functionality and run against the existing code. (In the case where the test is a
A minimal amount of code is then written, just enough to get the test to pass. Then the process is repeated for unit test for a function, it would be run against an empty (unimplemented) function.) The test
the next small piece of functionality. This continues until all the functionality has been implemented. 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.
This approach has two advantages: This approach has two advantages:
- By writing a test first and then only enough code to pass the test, that code is fully tested. By repeating - By writing a test first and then only enough code to pass the test, that code is fully tested. By
this process until the feature is fully implemented, all the code gets test coverage. You avoid the situation repeating this process until the feature is fully implemented, all the code gets test
where not enough tests have been written to check all the code. coverage. You avoid the situation where not enough tests have been written to check all the
- By running the test before the code implementing the function is written and observing the test fail, you can code.
detect the situation where a bug in the test code will cause it to pass regardless of the code being tested.
Initially, some people unfamiliar with that approach react with "but my change is simple and I tested that it - By running the test before the code implementing the function is written and observing the test
works". That approach is both insufficient and short-sighted. It is insufficient, because manual testing is by fail, you can detect the situation where a bug in the test code will cause it to pass regardless
definition laborious and can't really be done on the multitude of systems we run Kea on. It is short-sighted, of the code being tested.
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.
See Building Kea with Unit Tests for instructions on how to run unit-tests. If you happen to touch any database Initially, some people unfamiliar with that approach react with "but my change is simple and I
related code, make sure you compile your code with –with-mysql, –with-pgsql and/or –with-cql as needed. For example, tested that it works". That approach is both insufficient and short-sighted. It is insufficient,
if you change something substantial, make sure the other compilation options still work. 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.
If you happen to add new files or have modified any Makefile.am files, it is also a good idea to check if you haven't See Building Kea with Unit Tests for instructions on how to run unit-tests. If you happen to touch
broken the distribution process: 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 Makefile.am files, it is also a good idea to
check if you haven't broken the distribution process:
```bash ```bash
make distcheck make distcheck
``` ```
There are other useful switches which can be passed to configure. It is always a good idea to use `–enable-logger-checks`, There are other useful switches which can be passed to configure. It is always a good idea to use
which does sanity checks on logger parameters. Use `–-enable-debug` to enable various additional consistency checks `–enable-logger-checks`, which does sanity checks on logger parameters. Use `–-enable-debug` to
that reduce performance but help during development. If you happen to modify anything in the documentation, use enable various additional consistency checks that reduce performance but help during development. If
`–-enable-generate-docs`. If you are modifying DHCP code, you are likely to be interested in enabling a non-default you happen to modify anything in the documentation, use `–-enable-generate-docs`. If you are
database backends for DHCP. Note that if the backend is not enabled, the database-specific unit-tests are skipped. modifying DHCP code, you are likely to be interested in enabling a non-default database backends for
To enable the MySQL backend, use the switch `–with-mysql`; for PostgreSQL, use `–with-pgsql` and for Cassandra use DHCP. Note that if the backend is not enabled, the database-specific unit-tests are skipped. To
`--with-cql`. A complete list of all switches can be obtained with the command: 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:
```bash ```bash
./configure --help ./configure --help
@@ -91,107 +113,139 @@ To enable the MySQL backend, use the switch `–with-mysql`; for PostgreSQL, use
## Submitting Merge Request (also known as sending your patch the right way) ## Submitting Merge Request (also known as sending your patch the right way)
The first step in writing the patch or new feature should be to get the source code from our Git repository. The first step in writing the patch or new feature should be to get the source code from our Git
The procedure is very easy and is [explained here](https://gitlab.isc.org/isc-projects/kea/wikis/processes/gitlab-howto). repository. The procedure is very easy and is [explained
While it is possible to provide a patch against the latest stable release, it makes the review process much here](https://gitlab.isc.org/isc-projects/kea/wikis/processes/gitlab-howto). While it is possible
easier if it is for latest code from the Git master branch. 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.
ISC uses [gitlab](https://gitlab.isc.org) to manage its source code. While we also maintain presence on [github](https://github.com/isc-projects/kea), ISC uses [gitlab](https://gitlab.isc.org) to manage its source code. While we also maintain presence
the process of syncing gitlab to github is mostly automated and Kea devs rarely look at github. on [github](https://github.com/isc-projects/kea), the process of syncing gitlab to github is mostly
automated and Kea devs rarely look at github.
ISC's gitlab has been a target for spammers in the past, so it is now set up defensively. In particular, new users ISC's gitlab has been a target for spammers in the past, so it is now set up defensively. In
can't fork the code on their own and it requires someone from ISC to manually grant the ability to fork projects. particular, new users can't fork the code on their own and it requires someone from ISC to manually
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 grant the ability to fork projects. Fortunately, this is easy to do and we glady do this for anyone
bug X or develop feature Y" is an excellent reason. The best place for asking is either kea-dev or asking in a comment who asks and provides a good reason. "I'd like to fix bug X or develop feature Y" is an excellent
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 reason. The best place for asking is either kea-dev or asking in a comment in your issue. Make sure
request and add a name tag on it, the user is automatically notified. 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.
Once you fork the Kea code in gitlab, you have your own copy and you can commit your changes there and push them Once you fork the Kea code in gitlab, you have your own copy and you can commit your changes there
to your copy of Kea repo. Once you feel that your patch is ready, go to Kea project and [submit a Merge Request](https://gitlab.isc.org/isc-projects/kea/merge_requests/new). 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](https://gitlab.isc.org/isc-projects/kea/merge_requests/new).
If you can't access this link or don't see New Merge Request button on the [merge requests page](https://gitlab.isc.org/isc-projects/kea/merge_requests), If you can't access this link or don't see New Merge Request button on the [merge requests
please ask on kea-dev and someone will help you out. page](https://gitlab.isc.org/isc-projects/kea/merge_requests), please ask on kea-dev and someone
will help you out.
## Send Pull Request on github ## Send Pull Request on github
If you can't send the patch on gitlab, the next best preferred way is to send pull request (PR) on [github](https://github.com/isc-projects/kea).
This is almost as good as sending MR on gitlab. The downside is that Kea devs don't look at github too frequently, If you can't send the patch on gitlab, the next best preferred way is to send pull request (PR) on
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 [github](https://github.com/isc-projects/kea).
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 gitlab.
See the excellent documentation on github: https://help.github.com/articles/creating-a-pull-request/ for details. This is almost as good as sending MR on gitlab. The downside is that Kea devs don't look at github
\In essence, you need github account (spam/hassle free, takes one minute to set up). Then you can fork the Kea too frequently, so it may be a while before we notice it. And when we do, the chances are we will be
repository, commit changes to your repo and ask us to pull your changes into official Kea repository. This has a busy with other things. With gitlab, your MR will stare at us the whole time, so we'll get round to
number of advantages. First, it is made against a specific code version, which can be easily checked with git log it much quicker. But we understand that there are some cases where people may prefer github over
command. Second, this request pops up instantly on our list of open pull requests and will stay there. The third gitlab.
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 See the excellent documentation on github: https://help.github.com/articles/creating-a-pull-request/
to your repository. Those extra commits will appear instantly in the pull request. This is really useful during for details. In essence, you need github account (spam/hassle free, takes one minute to set
the review. Finally, Kea developers can better assess all open pull requests and add labels to them, such as up). Then you can fork the Kea repository, commit changes to your repo and ask us to pull your
"enhancement", "bug", or "unit-tests missing". This makes our life easier. Oh, and your commits will later be shown changes into official Kea repository. This has a number of advantages. First, it is made against a
as yours in github history. If you care for that kind of things, once the patch is merged, you'll be automatically specific code version, which can be easily checked with git log command. Second, this request pops
listed as contributor and Kea will be listed as project you have contributed to. 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.
## If you really can't do MR on gitlab or PR on github... ## If you really can't do MR on gitlab or PR on github...
Well, you are out of luck. There are other ways, but those are really awkward and the chances of your patch Well, you are out of luck. There are other ways, but those are really awkward and the chances of
being ignored are really high. Anyway, here they are: your patch being ignored are really high. Anyway, here they are:
- [create an issue in the Kea Gitlab](https://gitlab.isc.org/isc-projects/kea/issues/new) and attach your patch to it. Sending - [create an issue in the Kea Gitlab](https://gitlab.isc.org/isc-projects/kea/issues/new) and attach
a patch has a number of disadvantages. First, if you don't specify the base version against which it was created, your patch to it. Sending a patch has a number of disadvantages. First, if you don't specify the
one of Kea developers will have to guess that or go through a series of trials and errors to find that out. If the base version against which it was created, one of Kea developers will have to guess that or go
code doesn't compile, the reviewer will not know if the patch is broken or maybe it was applied to incorrect base through a series of trials and errors to find that out. If the code doesn't compile, the reviewer
code. Another frequent problem is that it may be possible that the patch didn't include any new files you have added. will not know if the patch is broken or maybe it was applied to incorrect base code. Another
If we happen to have any comments that you as submitter are expected to address (and in the overwhelming majority of frequent problem is that it may be possible that the patch didn't include any new files you have
cases, we have), you will be asked to send an updated patch. It is not uncommon to see several rounds of such reviews, added. If we happen to have any comments that you as submitter are expected to address (and in
so this can get very complicated very quickly. Please don't add your issue to any milestone. Kea team has a process the overwhelming majority of cases, we have), you will be asked to send an updated patch. It is
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 not uncommon to see several rounds of such reviews, so this can get very complicated very
you did with the code and announce the issue number. 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 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. - 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.
## Going through a review ## Going through a review
Once you make your patch available using one of the ways above, the action is on Once you make your patch available using one of the ways above, the action is on one of the Kea
one of the Kea developers. We need an issue. While we can create it on our own, developers. We need an issue. While we can create it on our own, we prefer the original submitter
we prefer the original submitter fill them in as he or she has the best fill them in as he or she has the best understanding of the purpose of the change and may have any
understanding of the purpose of the change and may have any extra information extra information about OS, version, why it was done this specific way etc. If there is no MR and no
about OS, version, why it was done this specific way etc. If there is no MR and gitlab issue, you risk the issue not showing up on ISC radars. Depending on the subjective
no gitlab issue, you risk the issue not showing up on ISC radars. Depending on importance and urgency as perceived by the ISC engineer, the issue or PR will be assigned to one of
the subjective importance and urgency as perceived by the ISC engineer, the the milestones.
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 Sooner or later, one of Kea developers will do the review. Here's the tricky part. One of Kea
review your patch, but it may not happen immediately. Unfortunately, developers are usually working under a tight developers will review your patch, but it may not happen immediately. Unfortunately, developers are
schedule, so any extra unplanned review work may take a while. Having said that, we value external usually working under a tight schedule, so any extra unplanned review work may take a while. Having
contributions very much and will do whatever we can to review patches in a timely manner. Don't get discouraged said that, we value external contributions very much and will do whatever we can to review patches
if your patch is not accepted after first review. To keep the code quality high, we use the same review processes in a timely manner. Don't get discouraged if your patch is not accepted after first review. To keep
for external patches as we do for internal code. It may take some cycles of review/updated patch submissions the code quality high, we use the same review processes for external patches as we do for internal
before the code is finally accepted. The nature of the review process is that it emphasizes areas that need code. It may take some cycles of review/updated patch submissions before the code is finally
improvement. If you are not used to the review process, you may get the impression that the feedback is negative. accepted. The nature of the review process is that it emphasizes areas that need improvement. If you
It is not: even the Kea developers seldom see reviews that say "All OK please merge". 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. Once the process is almost complete, the developer will likely ask you how you would like to be
The typical answers are by first and last name, by nickname, by company name or anonymously. Typically we will credited. The typical answers are by first and last name, by nickname, by company name or
add a note to the ChangeLog and also set you as the author of the commit applying the patch and update the anonymously. Typically we will add a note to the ChangeLog and also set you as the author of the
contributors section in the AUTHORS file. If the contributed feature is big or critical for whatever reason, commit applying the patch and update the contributors section in the AUTHORS file. If the
it may also be mentioned in release notes. contributed feature is big or critical for whatever reason, it may also be mentioned in release
notes.
Sadly, we sometimes see patches that are submitted and then the submitter never responds to our comments or requests Sadly, we sometimes see patches that are submitted and then the submitter never responds to our
for an updated patch. Depending on the nature of the patch, we may either fix the outstanding issues on our own and comments or requests for an updated patch. Depending on the nature of the patch, we may either fix
get another Kea developer to review them or the issue may end up in our Outstanding milestone. When a new the outstanding issues on our own and get another Kea developer to review them or the issue may end
release is started, we go through the issues in Outstanding, select a small number of them and move them up in our Outstanding milestone. When a new release is started, we go through the issues in
to whatever the current milestone is. Keep that in mind if you plan to submit a patch and forget about it. We may Outstanding, select a small number of them and move them to whatever the current milestone is. Keep
accept it eventually, but it's much, much faster process if you participate in it. 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.
## Extra steps ## Extra steps
If you are interested in knowing the results of more in-depth testing, you are welcome to visit the ISC Jenkins If you are interested in knowing the results of more in-depth testing, you are welcome to visit the
page: https://jenkins.isc.org This is a live result page with all tests being run on various systems. Besides ISC Jenkins page: https://jenkins.isc.org This is a live result page with all tests being run on
basic unit-tests, we also have reports from valgrind (memory debugger), cppcheck and clang-analyzer (static code various systems. Besides basic unit-tests, we also have reports from valgrind (memory debugger),
analyzers), Lettuce system tests and more. Although it is not possible for non ISC employees to run tests on that cppcheck and clang-analyzer (static code analyzers), Lettuce system tests and more. Although it is
farm, it is possible that your contributed patch will end up there sooner or later. We also have ISC Forge tests not possible for non ISC employees to run tests on that farm, it is possible that your contributed
running, but currently the test results are not publicly available. patch will end up there sooner or later. We also have ISC Forge tests running, but currently the
test results are not publicly available.