BIND 10 trac3109, updated. 342c56224c215ca1cb245df0875878e4f8fad0e6 [3109] Re-justify paragraphs (after changes in previous commits)
BIND 10 source code commits
bind10-changes at lists.isc.org
Thu Sep 12 07:34:05 UTC 2013
The branch, trac3109 has been updated
via 342c56224c215ca1cb245df0875878e4f8fad0e6 (commit)
via 273b3105e21cfa457381983bf0c98f2590c55ebd (commit)
via e2dbd7090ae49267e0ff14f593de49629afbf710 (commit)
via f83c6c44a65b4cb04d3e2691e5bf0a3bf82d59c0 (commit)
via 3b9c90d00e5b0c2790a9d7c94b8765b61a6b64a0 (commit)
via 1e278e019742e8f13b93d6f670d50eb14e675217 (commit)
via 677e0bd0a52306ea81f3a7bab51257ffc466b856 (commit)
via 2f3324cbeeada97f94105d9c8ce902f496e34dd3 (commit)
via 37bb1f516ee852871f61b92d7bb5f50ba79a4b0f (commit)
via 19cb9064139e3b2adcf26bef7d7fdd38db356010 (commit)
via 3f5af01217a8e67822a9a25744b06579390a57f5 (commit)
from 8bf74aab112eeac3471cc9d9ebdfb74cac970176 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 342c56224c215ca1cb245df0875878e4f8fad0e6
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 13:03:50 2013 +0530
[3109] Re-justify paragraphs (after changes in previous commits)
commit 273b3105e21cfa457381983bf0c98f2590c55ebd
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 13:03:22 2013 +0530
[3109] Update text
commit e2dbd7090ae49267e0ff14f593de49629afbf710
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 13:00:20 2013 +0530
[3109] Re-justify paragraphs (after changes in previous commits)
commit f83c6c44a65b4cb04d3e2691e5bf0a3bf82d59c0
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 12:59:52 2013 +0530
[3109] Update text
commit 3b9c90d00e5b0c2790a9d7c94b8765b61a6b64a0
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 12:54:00 2013 +0530
[3109] Re-justify paragraphs (after changes in previous commits)
commit 1e278e019742e8f13b93d6f670d50eb14e675217
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 12:53:48 2013 +0530
[3109] Update text
commit 677e0bd0a52306ea81f3a7bab51257ffc466b856
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 12:52:13 2013 +0530
[3109] Move paragraphs to maintain context
commit 2f3324cbeeada97f94105d9c8ce902f496e34dd3
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 12:51:49 2013 +0530
[3109] Re-justify paragraph (after changes in previous commits)
commit 37bb1f516ee852871f61b92d7bb5f50ba79a4b0f
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 12:50:41 2013 +0530
[3109] Update text
commit 19cb9064139e3b2adcf26bef7d7fdd38db356010
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 12:48:13 2013 +0530
[3109] Re-justify paragraph (after changes in previous commits)
commit 3f5af01217a8e67822a9a25744b06579390a57f5
Author: Mukund Sivaraman <muks at isc.org>
Date: Thu Sep 12 12:47:18 2013 +0530
[3109] Update text
-----------------------------------------------------------------------
Summary of changes:
doc/devel/contribute.dox | 109 ++++++++++++++++++++++++----------------------
1 file changed, 57 insertions(+), 52 deletions(-)
-----------------------------------------------------------------------
diff --git a/doc/devel/contribute.dox b/doc/devel/contribute.dox
index 7e808ff..af5142a 100644
--- a/doc/devel/contribute.dox
+++ b/doc/devel/contribute.dox
@@ -66,15 +66,17 @@ it before re-submitting.
One of the ground rules in BIND10 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, it is encouraged to write unit-test for that
+like a single line fix, it is 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.
-BIND10 uses google test (gtest) framework as a base for our
-unit-tests. See http://code.google.com/p/googletest/ for details.
-You must have gtest installed or at least compiled before compiling
-BIND10 unit-tests. To enable unit-tests in BIND10
+BIND10 uses the Google C++ Testing Framework (also called googletest or
+gtest) as a base for our C++ unit-tests. See
+http://code.google.com/p/googletest/ for details. For Python unit-tests,
+we use the its \c unittest library which is included in Python. You must
+have \c gtest installed or at least extracted in a directory before
+compiling BIND10 unit-tests. To enable unit-tests in BIND10, use:
@code
./configure --with-gtest=/path/to/your/gtest/dir
@@ -86,69 +88,72 @@ or
./configure --with-gtest-source=/path/to/your/gtest/dir
@endcode
-There are other useful switches passed to configure. It is always a good
-idea to use --enable-logger-checks, which does sanity checks on logger
-parameters. 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 MySQL backend for DHCP. Keep note that if the backend
-is not enabled, MySQL specific unit-tests are skipped, too. From that
-perspective, it is useful to use --with-dhcp-mysql parameter. For a
-complete list of all switches, use:
+Depending on how you compiled or installed \c gtest (e.g. from sources
+or using some package management system) one of those two switches will
+find \c gtest. After that you make run unit-tests:
@code
- ./configure --help
+make check
@endcode
-Depending on how you compiled or installed (e.g. from sources or using
-some package management system) one of those two switches will find
-gtest. After that you make run unit-tests:
+If you happen to add new files or have modified any \c Makefile.am
+files, it is also a good idea to check if you haven't broken the
+distribution process:
@code
-make check
+make distcheck
@endcode
-If you happen to add new files or modified Makefiles, it is also a
-good idea to check if you haven't broken distribution process:
+There are other useful switches which can be passed to configure. It is
+always a good idea to use \c --enable-logger-checks, which does sanity
+checks on logger parameters. If you happen to modify anything in the
+documentation, use \c --enable-generate-docs. If you are modifying DHCP
+code, you are likely to be interested in enabling the MySQL backend for
+DHCP. Note that if the backend is not enabled, MySQL specific unit-tests
+are skipped. From that perspective, it is useful to use
+\c --with-dhcp-mysql. For a complete list of all switches, use:
@code
-make distcheck
+ ./configure --help
@endcode
@section contributorGuideReview Going through a review
-Once all those are checked and working, feel free to create a ticket
-for your patch (http://bind10.isc.org) or attach your patch to the
-existing ticket if there is one. You may drop a note to bind10 or dhcp
-chatroom saying that you have submitted a patch. Alternatively, you
-may send a note to bind10-dev or bind10-dhcp lists.
-
-Here's the tricky part. One of BIND10 developers will review your
-patch, but it may not happen immediately. Unfortunately, developers
-are usually working under tight schedule, so any extra unplanned
-review work sometimes make 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 internal code and for
-external patches. It may take several cycles of review/updated patch
-submissions before the code is finally accepted.
-
-Once the process is almost completed, the developer will likely ask
-you how you would like to be credited. The typical answers are by
-first,last name, by nickname, by company or anonymously. Typically we
-will add a note to ChangeLog. If the contributted feature is big or
-critical for whatever reason, it may be also mentioned in release
-notes.
+Once all those are checked and working, feel free to create a ticket for
+your patch at http://bind10.isc.org/ or attach your patch to an existing
+ticket if you have fixed it. It would be nice if you also join the
+\c bind10 or \c dhcp chatroom saying that you have submitted a
+patch. Alternatively, you may send a note to the \c bind10-dev or
+\c bind10-dhcp mailing lists.
+
+Here's the tricky part. One of BIND10 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 sometimes. 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 internal code and for external patches. It may take
+some cycles of review/updated patch submissions before the code is
+finally accepted.
+
+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 \c ChangeLog and also set you as the author of
+the commit applying the patch. If the contributted feature is big or
+critical for whatever reason, it may also be mentioned in release notes.
@section contributorGuideExtra Extra steps
-If you are interested in even more in-depth testing, you are welcome
-to visit BIND10 build farm: http://git.bind10.isc.org/~tester/builder/builder-new.html
-This is a life result page with all tests being run on various systems.
-Besides basic unit-tests, we also run them with valgrind (memory debugger),
-with cppcheck and scan-build (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.
+If you are interested in knowing the results of more in-depth testing,
+you are welcome to visit the BIND10 build farm:
+http://git.bind10.isc.org/~tester/builder/builder-new.html. 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.
*/
More information about the bind10-changes
mailing list