Testing Python3

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> 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, I tend to run through my checklist then, too.

> 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.

That should have been #2 on the list after running ntpmon. Sometimes I do it
first.

> 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?

None at all. You have way more NTP ops experience than me; that makes
you better qualified.

I think you already have the beginnings of a procedure document under devel/.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.