Time for a release?

[James Browning]

> On 10/29/2023 10:50 PM PDT Hal Murray via devel <devel at 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.