devel/README

@@ -28,6 +28,9 @@ ntpv5.txt::
 packaging.txt::
 	Guidance for binary package builders.
 
+pre-release.txt::
+	A collection of ideas about testing before a release.
+
 release::
 	Script for shipping a release.
 

devel/pre-release.txt

+This is a collection of ideas about how/what to test when
+we are preparing for a release.  Most of them require
+manual action.
+
+It assumes we have a release candidate tarball and git tag.
+
+
+We should probably make a web page so we can collect check-boxes
+when we get reports that something works and graphs of typical
+operations so we have a reference for the next release.
+
+
+The first step is to make sure it builds cleanly on as many
+OSes/distros as we can.
+
+The second step is to make sure it runs.  Unfortunately, "it"
+gets complicated due to the collection of features and options
+and the possible interactions.
+
+In this context, we should treat different versions of
+an OS/distro as separate items.
+
+Similarly, we should have separate slots within an OS/distro
+for different hardware platforms.  The obvious platforms are
+Intel-64, Intel-32, ARM-32.  ARM-64 would be nice but I don't
+know if that is ready yet. (Jan 2017)
+
+We really need to test on an other-endian platform.
+NetBSD runs Big Endian on some ARM systems.
+  https://wiki.netbsd.org/ports/evbarm/allwinner/
+
+We should try as many refclocks as we can on as many
+OS/distros as we can.  This is testing the OS kernel
+as well as ntpd.  If possible, we should at least test
+the NMEA driver with the PPS driver and via SHM.
+
+Note that there are two levels of PPS to test.  The first
+is just being able to get the data.  The second is to see
+if the in-kernel PLL as activated by flag3 on the PPS driver
+works.  On Linux, that needs building a custom kernel with
+CONFIG_NO_HZ turned off and CONFIG_NTP_PPS on.
+
+
+We should review any documentation for best-practices and verify
+that any sample code and build recipies work as expected.  In
+particular, we should make sure the pool option works and that
+the Raspberry Pi Stratum 1 server HOWTO works.
+(There are two sample ntp.conf files in contrib/
+Both use the pool.  Jan 2017)
+
+
+We should bump the clock (ntpfrob -b) and watch how it recovers.
+We should probably do this on every OS.
+There should be 4 cases.  For small excursions,
+less than 128 ms, the clock should be adjusted.  For most OSes,
+it will slew.  For larger excursions, the clock will be stepped.
+If the clock is way off (over 600 seconds), ntpd should panic
+and exit, expecting a human to fix it.  The -g command line switch
+will override that panic and allow one big step.
+
+We should test cold-start with no drift file.
+
+xx
+  All the options in ntp.conf, debug, crypto

docs/includes/ntpd-body.txt

@@ -324,7 +324,7 @@ rarely strays more than 128 ms even under extreme cases of network path
 congestion and jitter. Sometimes, in particular when +ntpd+ is first
 started without a valid drift file on a system with a large intrinsic
 drift the error might grow to exceed 128 ms, which would cause the clock
-to be set backwards if the local clock time is more than 128 s in the
+to be set backwards if the local clock time is more than 128 ms in the
 future relative to the server. In some applications, this behavior may
 be unacceptable. There are several solutions, however. If the +-x+
 option is included on the command line, the clock will never be stepped

tests/libntp/timespecops.c

@@ -60,7 +60,7 @@ static struct timespec timespec_init(time_t hi, long lo)
 static bool AssertFpClose(const l_fp m, const l_fp n, const l_fp limit)
 {
 	int64_t diff = m - n;
-	if ((l_fp)labs(diff) <= limit)
+	if ((l_fp)llabs(diff) <= limit)
 		return true;
 	else {
 		printf("m_expr which is %s \nand\nn_expr which is %s\nare not close; diff=%susec\n", lfptoa(m, 10), lfptoa(n, 10), lfptoa(diff, 10));