Commit 0cd94b5e authored by Thomas Markwalder's avatar Thomas Markwalder

[#64,!35] Restored work

    Restored cummulative work.
parent 97c15527
*.lo *.lo
*.o *.o
bind
doc/html doc/html
.deps .deps
Makefile Makefile
......
...@@ -3,52 +3,114 @@ ...@@ -3,52 +3,114 @@
So you found a bug in ISC DHCP or plan to develop an extension and want to send us a patch? Great! So you found a bug in ISC DHCP or plan to develop an extension and want to send us a patch? Great!
This page will explain how to contribute your changes smoothly. This page will explain how to contribute your changes smoothly.
## Writing a patch We do not require a contributors agreement. By submitting a patch or merge request to this project,
you are agreeing that your code will be covered by the primary license for the project.
ISC DHCP is currently licensed under the MPL2.0 license.
Here's are the steps in contributing a patch:
1. **create account** on [gitlab](https://gitlab.isc.org)
2. **open an issue** in [this project](https://gitlab.isc.org/isc-projects/dhcp/issues/new), make sure
it describes what you want to fix and **why**. ISC DHCP is very mature code, with a large installed base.
We are fairly conservative about making changes unless there is a very good reason.
3. **ask someone from the ISC team to give you a 'project allocation' so you can to fork ISC DHCP in our repo** (ask on the issue - mention @tomek, @vicky, @ondrej
or @godfryd if it seems we haven't noticed your request)
4. **fork the DHCP master branch**: go to the DHCP project page, click the [Fork button](https://gitlab.isc.org/isc-projects/dhcp/forks/new).
If you can't, you didn't complete step 3. It helps to include the issue number and subject in the branch name.
5. **Implement your fix or feature, in your branch**. Make sure it compiles, has unit-tests,
is documented and does what it's supposed to do.
6. **Open Merge Request**: go to the DHCP project [merge requests page](https://gitlab.isc.org/isc-projects/dhcp/merge_requests), and
click [New merge request](https://gitlab.isc.org/isc-projects/dhcp/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.
See the text below for more details.
## Create an issue
The first step in contributing to ISC DHCP is to [create an issue](https://gitlab.isc.org/isc-projects/dhcp/issues/new), describing the problem, deficiency
or missing feature you want to address. It is important to make it very clear why the specific change
you are proposing should be made. ISC DHCP is very mature code, with a large and somewhat inert installed base.
We are very cautious about introducing changes that could break existing functionalty. If you want to fix
multiple problems, or make multiple changes, please make separate issues for each.
## Plan your changes
Before you start working on a patch or a new feature, it is a good idea to discuss it first with Before you start working on a patch or a new feature, it is a good idea to discuss it first with
DHCP developers. You can post your questions to the [dhcp-workers](https://lists.isc.org/mailman/listinfo/dhcp-workers) DHCP developers. You may benefit from reading the [ISC DHCP Developer's Survival Guide](https://gitlab.isc.org/isc-projects/dhcp/wikis/home)
or [dhcp-users](https://lists.isc.org/mailman/listinfo/dhcp-users) mailing lists. The dhcp-users is posted on the wiki page for this repo.
intended for users who are not interested in the internal workings or development details: it is
OK to ask for feedback regarding new design or the best proposed solution to a certain problem. You can post questions about development on the [dhcp-workers](https://lists.isc.org/mailman/listinfo/dhcp-workers)
This is the best place to get user's feedback. The internal details, questions about the code and or [dhcp-users](https://lists.isc.org/mailman/listinfo/dhcp-users) mailing lists. Dhcp-users is
its internals are better asked on dhcp-workers. The dhcp-workers is a very low traffic list. intended for users who are not interested in development details: it is appropriate to ask for
feedback regarding the best proposed solution to a certain problem. The internal details,
OK, so you have written a patch? Great! Before you submit it, make sure that your code compiles. questions about the code and its internals are better asked on dhcp-workers. The dhcp-workers
This may seem obvious, but there's more to it. You have surely checked that it compiles on your list is a very low traffic list.
system, but ISC DHCP 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 ## Create a branch for your work
expected to run on many other architectures. For a complete list of systems we build on, you may
take a look at the [Jenkins build farm report](https://jenkins.isc.org/view/isc-dhcp/). These instructions assume you will be making your changes on a branch in the ISC DHCP Gitlab
repository. This is by far the easiest way for us to collaborate with you. While we also maintain a presence
## Running unit-tests on [Github](https://github.com/isc-projects/dhcp), ISC developers rarely look at Github, which is
just a mirror of our Gitlab system.
ISC's Gitlab has been a target for spammers, so it is set up defensively. New users need permission
from ISC to create new projects. We gladly 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. To request a project
allocation in ISC's Gitlab, just ask for it in a comment in your issue. Make sure
you tag someone at ISC (@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 are given a 'project allocation' in our Gitlab, you can fork ISC DHCP and create a branch.
This is your copy of ISC DHCP and is where you will make your changes. Go to the DHCP project page,
click the [Fork button](https://gitlab.isc.org/isc-projects/dhcp/forks/new) and you will be prompted
to name your branch. It helps to include the issue number and subject in the branch name. You can make
changes to this branch without worrying that you will impact the master branch - commit priviliges
are restricted so you cannot accidentally alter the master branch.
Please read the [Gitlab How-To](https://gitlab.isc.org/isc-projects/dhcp/wikis/processes/gitlab-howto) for ISC DHCP.
## Implement your change
Please try to conform to the project's coding standards. ISC DHCP uses the same [coding standards](https://gitlab.isc.org/isc-projects/bind9/blob/master/doc/dev/style.md) as the BIND 9 project. https://gitlab.isc.org/isc-projects/bind9/blob/master/doc/dev/style.md
## Compile your code
We don't yet have continuous integration set up for ISC DHCP, so you have to check the compilation manually.
ISC DHCP is used on a wide array of UNIX and Linux operating systems. 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. .
## Run unit-tests
One of the ground rules in all ISC projects is that every piece of code has to be tested. For newer One of the ground rules in all ISC projects is that every piece of code has to be tested. For newer
projects, such as Kea, we require unit-test for almost every line of code. For older code, such as projects, we require a unit-test for almost every line of code. For older code, such as
ISC DHCP, that was not developed with testability in mind, it's unfortunately impractical to require ISC DHCP, that was not developed with testability in mind, it's unfortunately impractical to require
extensive unit-tests. Having said that, please think thoroughly if there is any way to develop extensive unit-tests. Having said that, please think thoroughly if there is any way to develop
unit-tests. The long term goal is to improve the situation. unit-tests. The long term goal is to improve the situation.
Where unit tests are not practical, supplying us with things like configuration file(s), lease file(s),
PCAPS, and step-by-step on how you tested the changes would be a big help. This will aid us in
creating and adding system tests to the build farm.
You should have also conducted some sort of system testing to verify that your changes do what you You should have also conducted some sort of system testing to verify that your changes do what you
want. It would be extremely helpful if you can attach any configuration files (dhcpd and or want. It would be extremely helpful if you can attach any configuration files (dhcpd and or
dhclient), along with a step-by-step procedure to carry out the test(s). This will help us verify dhclient), along with a step-by-step procedure to carry out the test(s). This will help us verify
your changes as extend our own system tests. your changes as extend our own system tests.
Building ISC DHCP code from the repository is slightly different than the release tarballs. One
major difference is that it does not have BIND source bundled inside and those have to be
downloaded separately. Fortunately, there's an easy to use script for that:
```bash
sh util/bind.sh v4_4
./configure --with-atf
make
```
Make sure you have ATF (Automated Test Framework) installed in your system. For more information Make sure you have ATF (Automated Test Framework) installed in your system. For more information
about ATF, please refer to <dhcp source tree>/doc/devel/atf.dox. Note, running "make devel" in this about ATF, please refer to <dhcp source tree>/doc/devel/atf.dox. Note, running "make devel" in this
directory will generate the documentation. To run the unit-tests, simply run: directory will generate the documentation. To run the unit-tests, simply run:
```bash ```bash
./configure --with-atf
make
make check make check
``` ```
...@@ -66,37 +128,19 @@ can be obtained with the command: ...@@ -66,37 +128,19 @@ can be obtained with the command:
./configure --help ./configure --help
``` ```
## Create an issue ## Create a Merge Request
Since you want to change something in ISC DHCP, there's a problem, deficiency or a missing feature. Once you feel that your patch is ready, go to the DHCP project
Quite often it is not clear why specific change is being made. The best way to explain it is to
[create an issue here](https://gitlab.isc.org/isc-projects/dhcp/issues/new). We prefer the original
submitter fill them as he or she has the best understanding of the purpose of the change and may
have any extra information, e.g. "this patch fixes compilation issue on FreeBSD 10.1". If there there
is no MR and no gitlab issue, we will create one. Depending on the subjective importance and urgency
as perceived by the ISC engineer, the issue and/or MR will be assigned to one of the milestones.
## 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 procedure is very easy and is [explained here](https://gitlab.isc.org/isc-projects/dhcp/wikis/gitlab-howto).
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.
Since you won't get write access to the ISC DHCP repository, you should fork it and then commit
your changes to your own repo. How you organize the work depends entirely on you, but it seems
reasonable to create a branch rather than working on your master. Once you feel that your patch
is ready, please commit your changes and push it to your copy of ISC DHCP repo. Then go to DHCP project
and [submit a Merge Request](https://gitlab.isc.org/isc-projects/dhcp/merge_requests/new). and [submit a Merge Request](https://gitlab.isc.org/isc-projects/dhcp/merge_requests/new).
TODO: I don't think this is necessary. If you can't access this link or don't see New Merge Request If you can't access this link or don't see New Merge Request button on the [merge requests
button on the [merge requests page](https://gitlab.isc.org/isc-projects/dhcp/merge_requests) page](https://gitlab.isc.org/isc-projects/dhcp/merge_requests), please ask on dhcp-workers and someone
or the link gives you 404 error, please ask on dhcp-users and someone will help you out. will help you out.
Once you submit it, someone from the DHCP development team will look at it and will get back to you. Once you submit it, someone from the DHCP development team will look at it and will get back to you.
The dev team is very small, so it may take a while... The dev team is very small, so it may take a while...
## If you really can't do MR on gitlab... ## If you really can't do a merge request on ISC's Gitlab...
Well, you are out of luck. There are other ways, but those are really awkward and the chances of 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: your patch being ignored are really high. Anyway, here they are:
...@@ -116,23 +160,23 @@ your patch being ignored are really high. Anyway, here they are: ...@@ -116,23 +160,23 @@ your patch being ignored are really high. Anyway, here they are:
## Going through a review ## Going through a review
Once the MR is in the system, the action is on one of the ISC (and possibly other trusted) engineers. Once the merge request (MR) is in the system, the action is on one of the core developers.
Sooner or later, one of these engineers will do the review. Unfortunately, we have a small team
and we have a lot of users to support, so it may take a while for us to get to your patch.
Having said that, we value external contributions very much and will do whatever we
can to review patches in a timely manner.
Sooner or later, one of ISC engineers will do the review. Here's the tricky part. One of ISC DHCP Don't get discouraged if your patch is not accepted on the first review. To keep the code
developers will review your patch, but it may not happen immediately. Unfortunately, developers quality high, we use the same review processes for external patches as we do for internal code.
are usually working under a tight schedule, so any extra unplanned review work may take a while It may take some cycles of review/updated patch submissions before the code is finally accepted.
sometimes. Having said that, we value external contributions very much and will do whatever we The nature of the review process is that it emphasizes areas that need improvement. If you are
can to review patches in a timely manner. Don't get discouraged if your patch is not accepted not used to the review process, you may get the impression that the feedback is negative. It
after first review. To keep the code quality high, we use the same review processes for external is not: even the core developers seldom see reviews that say "All OK please merge".
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 ISC developers seldom see reviews that say "All OK
please merge".
If we happen to have any comments that you as submitter are expected to address (and in the 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 update your MR. It is not overwhelming majority of cases, we have), you will be asked to update your MR. It is common
uncommon to see several rounds of such reviews, so this can get very complicated very quickly. to see several rounds of such reviews.
Once the process is almost complete, the developer will likely ask you how you would like to be 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 credited. The typical answers are by first and last name, by nickname, by company name or
...@@ -143,18 +187,10 @@ notes. ...@@ -143,18 +187,10 @@ notes.
Sadly, we sometimes see patches that are submitted and then the submitter never responds to our 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 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 ISC engineer to review them or the ticket may end the outstanding issues on our own and get another engineer to review them or the ticket may end
up in our Outstanding milestone. When a new release is started, we go through the tickets in up in our Outstanding milestone. When a new release is started, we go through the tickets in
Outstanding, select a small number of them and move them to whatever the current milestone is. Keep 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 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. it's a much, much faster process if you participate in it.
## Extra steps
If you are interested in knowing the results of more in-depth testing, you are welcome to visit the #### Thank you for contributing your time and expertise to the ISC DHCP Project.
ISC Jenkins page: https://jenkins.isc.org This is a live result page with all tests being run on
various systems. Besides basic unit-tests, we also have reports from valgrind (memory debugger),
cppcheck and clang-analyzer (static code analyzers), Lettuce system tests and more. Although it
is not possible for non ISC employees to run tests on that farm, it is possible that your
contributed patch will end up there sooner or later. We also have ISC Forge tests running and other
additional tests, but currently those test results are not publicly available.
...@@ -40,6 +40,8 @@ endif ...@@ -40,6 +40,8 @@ endif
# to fool automake when the bind directory does not exist. # to fool automake when the bind directory does not exist.
SUBDIRS = @BINDSUBDIR@ includes tests common omapip client dhcpctl relay server SUBDIRS = @BINDSUBDIR@ includes tests common omapip client dhcpctl relay server
DIST_SUBDIRS = $(SUBDIRS) keama
nobase_include_HEADERS = dhcpctl/dhcpctl.h nobase_include_HEADERS = dhcpctl/dhcpctl.h
# #
......
# Makefile.in generated by automake 1.15 from Makefile.am. # Makefile.in generated by automake 1.16.1 from Makefile.am.
# @configure_input@ # @configure_input@
# Copyright (C) 1994-2014 Free Software Foundation, Inc. # Copyright (C) 1994-2018 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation # This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it, # gives unlimited permission to copy and/or distribute it,
...@@ -166,7 +166,7 @@ am__recursive_targets = \ ...@@ -166,7 +166,7 @@ am__recursive_targets = \
$(RECURSIVE_CLEAN_TARGETS) \ $(RECURSIVE_CLEAN_TARGETS) \
$(am__extra_recursive_targets) $(am__extra_recursive_targets)
AM_RECURSIVE_TARGETS = $(am__recursive_targets:-recursive=) TAGS CTAGS \ AM_RECURSIVE_TARGETS = $(am__recursive_targets:-recursive=) TAGS CTAGS \
cscope distdir dist dist-all distcheck cscope distdir distdir-am dist dist-all distcheck
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP) am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
# Read a list of newline-separated strings from the standard input, # Read a list of newline-separated strings from the standard input,
# and print each of them once, without duplicates. Input order is # and print each of them once, without duplicates. Input order is
...@@ -187,7 +187,6 @@ am__define_uniq_tagged_files = \ ...@@ -187,7 +187,6 @@ am__define_uniq_tagged_files = \
ETAGS = etags ETAGS = etags
CTAGS = ctags CTAGS = ctags
CSCOPE = cscope CSCOPE = cscope
DIST_SUBDIRS = $(SUBDIRS)
am__DIST_COMMON = $(srcdir)/Makefile.in \ am__DIST_COMMON = $(srcdir)/Makefile.in \
$(top_srcdir)/doc/devel/doxyfile.in README compile \ $(top_srcdir)/doc/devel/doxyfile.in README compile \
config.guess config.sub depcomp install-sh missing config.guess config.sub depcomp install-sh missing
...@@ -390,6 +389,7 @@ EXTRA_DIST = RELNOTES LICENSE configure.ac+lt config+lt \ ...@@ -390,6 +389,7 @@ EXTRA_DIST = RELNOTES LICENSE configure.ac+lt config+lt \
# Use an autoconf substitution vs an automake conditional here # Use an autoconf substitution vs an automake conditional here
# to fool automake when the bind directory does not exist. # to fool automake when the bind directory does not exist.
SUBDIRS = @BINDSUBDIR@ includes tests common omapip client dhcpctl relay server SUBDIRS = @BINDSUBDIR@ includes tests common omapip client dhcpctl relay server
DIST_SUBDIRS = $(SUBDIRS) keama
nobase_include_HEADERS = dhcpctl/dhcpctl.h nobase_include_HEADERS = dhcpctl/dhcpctl.h
# #
...@@ -558,7 +558,10 @@ distclean-tags: ...@@ -558,7 +558,10 @@ distclean-tags:
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags -rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
-rm -f cscope.out cscope.in.out cscope.po.out cscope.files -rm -f cscope.out cscope.in.out cscope.po.out cscope.files
distdir: $(DISTFILES) distdir: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) distdir-am
distdir-am: $(DISTFILES)
$(am__remove_distdir) $(am__remove_distdir)
test -d "$(distdir)" || mkdir "$(distdir)" test -d "$(distdir)" || mkdir "$(distdir)"
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ @srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
...@@ -623,7 +626,7 @@ distdir: $(DISTFILES) ...@@ -623,7 +626,7 @@ distdir: $(DISTFILES)
! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \ ! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r "$(distdir)" || chmod -R a+r "$(distdir)"
dist-gzip: distdir dist-gzip: distdir
tardir=$(distdir) && $(am__tar) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz tardir=$(distdir) && $(am__tar) | eval GZIP= gzip $(GZIP_ENV) -c >$(distdir).tar.gz
$(am__post_remove_distdir) $(am__post_remove_distdir)
dist-bzip2: distdir dist-bzip2: distdir
...@@ -649,7 +652,7 @@ dist-shar: distdir ...@@ -649,7 +652,7 @@ dist-shar: distdir
@echo WARNING: "Support for shar distribution archives is" \ @echo WARNING: "Support for shar distribution archives is" \
"deprecated." >&2 "deprecated." >&2
@echo WARNING: "It will be removed altogether in Automake 2.0" >&2 @echo WARNING: "It will be removed altogether in Automake 2.0" >&2
shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).shar.gz shar $(distdir) | eval GZIP= gzip $(GZIP_ENV) -c >$(distdir).shar.gz
$(am__post_remove_distdir) $(am__post_remove_distdir)
dist-zip: distdir dist-zip: distdir
...@@ -667,7 +670,7 @@ dist dist-all: ...@@ -667,7 +670,7 @@ dist dist-all:
distcheck: dist distcheck: dist
case '$(DIST_ARCHIVES)' in \ case '$(DIST_ARCHIVES)' in \
*.tar.gz*) \ *.tar.gz*) \
GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar) ;;\ eval GZIP= gzip $(GZIP_ENV) -dc $(distdir).tar.gz | $(am__untar) ;;\
*.tar.bz2*) \ *.tar.bz2*) \
bzip2 -dc $(distdir).tar.bz2 | $(am__untar) ;;\ bzip2 -dc $(distdir).tar.bz2 | $(am__untar) ;;\
*.tar.lz*) \ *.tar.lz*) \
...@@ -677,7 +680,7 @@ distcheck: dist ...@@ -677,7 +680,7 @@ distcheck: dist
*.tar.Z*) \ *.tar.Z*) \
uncompress -c $(distdir).tar.Z | $(am__untar) ;;\ uncompress -c $(distdir).tar.Z | $(am__untar) ;;\
*.shar.gz*) \ *.shar.gz*) \
GZIP=$(GZIP_ENV) gzip -dc $(distdir).shar.gz | unshar ;;\ eval GZIP= gzip $(GZIP_ENV) -dc $(distdir).shar.gz | unshar ;;\
*.zip*) \ *.zip*) \
unzip $(distdir).zip ;;\ unzip $(distdir).zip ;;\
esac esac
......
...@@ -92,7 +92,7 @@ by Eric Young (eay@cryptsoft.com). ...@@ -92,7 +92,7 @@ by Eric Young (eay@cryptsoft.com).
- A new configuration parameter, ping-cltt-secs (v4 operation only), has - A new configuration parameter, ping-cltt-secs (v4 operation only), has
been added to allow the user to specify the number of seconds that must been added to allow the user to specify the number of seconds that must
elapse since CLTT before a ping check is conducted. Prior to this, the elapse since CLTT before a ping check is conducted. Prior to this, the
value was hard coded at 60 seconds. Please see the server man pages for value was hard coded at 60 seconds. Please see the server man pages for
a more detailed discussion. a more detailed discussion.
[ISC-Bugs #36283] [ISC-Bugs #36283]
...@@ -102,7 +102,7 @@ by Eric Young (eay@cryptsoft.com). ...@@ -102,7 +102,7 @@ by Eric Young (eay@cryptsoft.com).
than in seconds (via ping-timeout). When greater than zero, the value than in seconds (via ping-timeout). When greater than zero, the value
of ping-timeout-ms will override the value of ping-timeout. Thanks of ping-timeout-ms will override the value of ping-timeout. Thanks
to Jay Doran from Bluecat Networks for suggesting this feature. to Jay Doran from Bluecat Networks for suggesting this feature.
[ISC-Bugs #10,!6 git ebe4f7ae427fa91f561a0b6e5f242de08d319a16] [Gitlab #10]