Testing Python3

[Hal Murray]

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.