> On 10/29/2023 10:50 PM PDT Hal Murray via devel <devel@ntpsec.org> wrote: > > The last time this was suggested, I encouraged waiting until we fixed mssntp. > Well, I think we have it fixed but we haven't found anybody to test it. > > So I think it's time to get ready for a release. > > Time for lots of testing. And documentation checking/cleanup. > > Does anybody have any features that should or must go in or bugs we should > fix? > (I haven't looked through issues yet.)
Highest priority MRs I have are 1331 and 1344. Bringing in some of the others would be nice. I want to rework 1341 though and now is not the time. Some of my other merge requests address issues that have been reported. > What is the policy on ntpq documentation? We have tuned the code for use > with our version of ntpd, but it still mostly(?) talks to the old > Mills/classic version. I noticed lots of references to multicast and > broadcast in the man page. We removed the code that supported that stuff > ages ago. The *cast references are now clutter if you are interested in our > code, but might be relevant if you are looking at an old old system. Should > we leave the *cast documentation in or clean it out? Huh, I'd have thought it would be in devel/hacking.adoc, maybe not. I suggest something like the following boilerplate... # Due to insecurabablility and dubious timing issue non unicat modes # are not supported in NTPsec, ntpq still supports reporting non- # unicast clocks to support legacy software. > I have 3 hacks that were used to debug talking to Samba. Is a subdir under > attic a reasonable place for them? I would have stuck them in contrib/. I don't think people consider me reasonable. I would've like to see !1173 and !1174 merged, but I think that time has passed. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
