Eric said: > I've never tried do describe that kind of testing because it's not easy to > tell people without prior experience running the clients what a success/ > failure indication looks like. Of course alarm bells would go off on a > crash, but the most definite thing I could say otherwise is "suspect a > problem if the number don't look lilke they usually do".
I think it's worthwhile to include some rough sanity checks in a get-ready-for-a-release document. Another time when that sort of check would be useful is before the push when making a significant change. Yes, it's hard to describe what success looks like. But the context is we are getting ready for a release or doing a big update, so the target audience is wizards rather then newbies. > I always do ntpmon first, as that test excerises the packet library pretty > well and would be more difficult to test jig than others becuse of the > ncurses otput. > I dump clock and system variables using ntpq to check that they look sane. > I test ntpdig and ntpwait. Good list. I'd put ntpq -p in there too. We should be explicit about how to "dump clock and system variables". I'm thinking of chunks you can copy-paste. Any objections if I write the text? Where should it go? -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
