This is free open source software. You can participate by sending bug reports, writing or fixing documentation, submitting patches or even new features. Answering questions on the public mailing lists is another great way to contribute to the community.
How to Become a Code Contributor
We use the Managed Open Source development model: only our staff are authorized committers to the source tree. This has the advantage of maintaining the performance and quality of the code base, and the disadvantage of making it a bit harder for external developers to contribute directly to the source code. l.
- Clone our read-only git for BIND9, ISC DHCP, or Kea
- Write your changes (this part is up to you, but see the BIND Developer, BIND Contributor Guidelines and BIND Coding style pages, or the Kea Developer’s Guide)
- For BIND, join our BIND Gitlab and create a merge request.
- For ISC DHCP, Email us a diff (instructions below).
- For Kea create a pull request on github. Our official github repos are under “ISC-Projects”.
- We review, may ask you for changes, and we commit to the primary repository
If you are attempting something complicated, or are investing a lot of your time and effort, you might want to consult some of the experts on bind-workers, dhcp-workers, or kea-dev for advice. Many of the frequent posters on bind-users are also occasional code contributors.
Useful information about our process
- BIND runs on Linux, Windows, BSD, OSX, Solaris, HP/UX and AIX. ISC DHCP runs on all of those platforms except for Windows. Please consider this. If your patch requires us to test and make changes for every other OS platform, we may not be able to accept it.
- The more information you can provide us about your patch, the better. If your patch fixes a defect, please give us a complete description of the bug, how to reproduce it, the version you found it in, whether you have verified it in other version, etc. If your patch enables new functionality, please explain what you want to achieve, and if it isn’t obvious, why.
- We prefer patches made to the current master branch, if possible. If you are submitting a patch for a defect only verified in a very old or unsupported version of BIND or ISC DHCP, we probably won’t accept it. We have to focus our efforts on supported code, and minimize changes of uncertain value.
- If you submit a new feature, we will have to hold onto it until the next major release goes out. We have a policy against putting significant new features into maintenance releases, for the obvious reason that they are de-stabilizing.
- We try to acknowledge new features that result from contributed patches in the release notes. We do not usually acknowledge contributed bug fixes, because it is harder to keep track of these, and often they are very small.
We accept two different types of code contribution: Code intended for inclusion in BIND, Kea or ISC DHCP itself, and code intended for the
- ISC does not require an explicit copyright assignment for patch contributions. However, by submitting a patch to ISC, you implicitly certify that you are the author of the code, that you intend to reliquish exclusive copyright, and that you grant permission to publish your work under whichever is the standard license agreement for the project you are submitting it for. (The license agreement depends on the project and software version, since we have changed our projects from the ISC license to the Mozilla Public License 2.0)
- External contributions must be licensed under a BSD-style license in order to be included in the contrib directory in our software distribution.
Submitting Patches - Fixes and Features
Patches for ISC DHCP and BIND may be submitted by email. When submitting a patch, please prepend the subject header with “[PATCH]” so it will be easier for us to find. If your patch introduces a new feature, please submit it to firstname.lastname@example.org or email@example.com; if it fixes a bug, please submit it to firstname.lastname@example.org or email@example.com. All submissions to the ticketing system receive an automatic response. Any followup email sent to the ticketing system should use the same subject header, so that it will be routed to the same ticket.