[ntp:questions] pool configuration directive on Windows
David L. Mills
mills at udel.edu
Thu Mar 6 18:06:25 UTC 2008
Things are very much worse than I thought. My understanding was that the
release version was divorced from the development version periodically
so the two at one time would be coincident and no release version would
occur until the next divorce. It makes no sense and is a waste of
resources to maintain two historic tracks well over a year divorced and
separately updated. Now the trackers have to know (a) when the latest
divorce occured, (b) when the latest release was carved and (c) what's
in the development branch.
Martin Burnicki wrote:
> David L. Mills wrote:
>>1. The pool command has been present for, in the scheme of things, for
>>some time, certainly before the latest release in September, 2007. If
>>so, why are we having this discussion?
> The release date of v4.2.4 was 2006-12-28, and the current point release
> v4.2.4p4 (the current -stable version) was published 2007-09-10.
> AFAIK only bug fixes have made their way into -stable after v4.2.4, but no
> new features like the "pool" command.
> Just grepping over the sources of both -dev and -stable shows that the word
> "pool" does not appear in the -stable branch, except in the contect of
> memory pools.
> In ntp-dev the word "pool" is listed as a keyword in ntp_config.c.
>>2. To what are you referring to about inverted restrict bits? I've heard
>>this urban legend before from several sources. The only change some time
>>ago was to the notrust bit. The interpretation was changed to deny
>>access --unless-- the server was correctly authenticated to the client.
>>Nothing was "inverted". You could help be spreading a new urban legend
>>to this effect.
> Yes, in fact I've been referring to the notrust bit:
> For a similar case see Ronan Flood's recent post (2008-02-26) under the
> thread "NTPD on bond0:0":
> "The sense of -L was reversed in ntpd 4.2.0: before that version, it meant
> listen to virtual IPs, after that version, it means do not listen to them."
>>3. I have been rather studious in announcing new features and
>>significatn changes to the hackers newsgroup. The archives of that group
>>should form an adequate electric paper trail, but it would have to be
>>correlated with the release dates.
> The problem here is when a "normal" NTP user tries to find whether a bug has
> already heen fixed in a certain version, or whether a feature is already
> available in a certain version, it's hard for him to find out.
> So for example the word "pool" can be found neither in the Changelog file of
> ntp-dev, nor in the commit logs of ntp-dev's BK repo, so it's hard to find
> when or in which version the "pool" feature has been introduced.
> Members of the hackers list may search their local mail archives when the
> "pool" keyword has been mentioned, then they have to determine whether the
> involved developers just started to discuss how to implement it, or when
> they finished to implement it.
> For people who are not on the hackers list and thus don't have local copies
> of the mails this is hard to do. Did you ever try to find a specific topic
> in the mailing list archives:
> You can review everything by date, thread, or download archives, but you can
> not search the archive for a keyword.
> (Steve or Brad, would it be possible to implement this?)
> Once a user has happened to find a specific email which documents when a
> feature has been added, they have to compare the date of that email to the
> dates when specific versions or tarballs have been release. Unfortunatey
> those dates are not even in the changelog files which come with the
> tarballs / distributions (I've recently suggested to Harlan to include
> those dates in the changelog).
> So they once again they have to search the mailing list or news group
> archives to find a mail or posting with the date when a specific version
> has been released.
>>4. There has been a serious upgrade effor for the documentation to
>>improve the style, reduce the lies and correct misconceptions, but it is
>>an ongoing effort. Much of that has already been incorporated in the
>>development branch documentaiton, including a sitemap anc command index.
>>However, I do not intend to create a back index documenting when changes
>>have been introduced other that the rather vague release notes.
> I think this is OK as long as it's made clear that this documentation refers
> only to the current development code.
> Anyway, I'd appreciate enhancements of the changelogs to simplify
> investigations whether a specific feature is available in a specific
> version of the NTP package.
More information about the questions