Hal Murray <[email protected]>:
>
> [email protected] said:
> >> How about setting up a simple script that at least tries all of the
> commands.
> > Hm. All it could detect is crashes. Time-varying output pretty scotches any
> > prospect of real regression testing.
>
> Yes, but it has a good chance of catching a large class of simple bugs.
True.
> In hindsight, I'm a bit surprised something like that isn't on your checklist
> already.
I've had a lot of other things to think about. Like this morning's CVE burst.
> We should do it with all the programs we build and again after we
> install things. If nothing else, it will verify that the libraries are
> linked correctly. The simple case would print out the version.
>
> It might be useful to have (or have waf build) a script that does the post
> install tests - something an admin could run after a system upgrade.
>
> We should have a config file that tests all the options for ntpd. It would
> need a command line switch so that it doesn't actually try to run anything.
> How about --check? That might be handy anyway. You could use it to check
> your changes to ntp.conf before restarting ntpd.
I'm not clear on how we'd tell good behavior from bad in that particular
context. It's easy to tell when ntpq crashes, but how do we know when ntpd
is processing an option wrongly?
Is this something you'd be willing to work on? You seem to have a clearer
vision of what the tests ought to be like, and I still have pre-1.0 work
to do getting ntpdig moved and writing ntpmon.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
devel mailing list
[email protected]
http://lists.ntpsec.org/mailman/listinfo/devel
