> Possibly, but to test some of the code paths (NTS) would take about a day. > Who wants to donate machine time for the runner?
We can test most of the NTS code paths in a few seconds. What did you have in mind for "about a day"? The NTS cookie key gets updated every 24 hours. The last-update-time is stored in the file. We could test the update path without waiting a long time by setting up a file that will expire in a few seconds. > Linux distros work, macOS some versions work, FreeBSD yes, NetBSD sorta, MS > no, and everyone else can check. What's the "sorta" for NetBSD? What do you mean by "can check"? The idea of this sort of data base is to save time on checking and/or to point out holes in our known coverage in hopes that somebody will test and report. I was thinking of a file or web page with a list of known tested cases. Maybe a line per case with OS/distro, version, CPU type, version/date of ntpsec, and date of test. There is a slight chicken/egg problem. You can't test a released version until it is released. > All refclocks are beleived to work. Again, some of the gear is pretty old. I'm sure Eric would be happy to nuke a few more drivers. I'd like to see somebody raise their hand and say "working for me" so we could add a version/date line in a file. Anybody using the modem driver? I don't think we need a full OS/version/driver matrix. There are probably enough quirks for some drivers that some notes would be useful. For example, the hpgps works with several GPSDOs. A list of known-working would be nice. I'm only interested in the current version of ntpsec. Maybe latest release and git head. I expect some of the reports in the collection would not get updated with every release. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
