pool configuration directive on Windows

Harlan Stenn wrote:[color=blue][color=green][color=darkred]
>>>> In article <fqpbr5$3c2$1@scrotar.nss.udel.edu>, "David L. Mills"
>>>> <mills@udel.edu> writes:[/color][/color]
>
> David> Martin, Things are very much worse than I thought. My understanding
> David> was that the release version was divorced from the development
> David> version periodically so the two at one time would be coincident and
> David> no release version would occur until the next divorce.
>
> This is what happens.
>
> And if a "significant" bug is found in -stable I make a "patch" release
> and fix it, generally because it will be "too long" to wait for the next
> time -dev is release as -stable and the divorce cycle starts again.[/color]

I agree this is a good way to handle this, so new features can "seetle"
before they go into a "stable" release, which is what the name "-stable"
implies.
[color=blue]
> David> It makes no sense and is a waste of resources to maintain two
> David> historic tracks well over a year divorced and separately updated.
>
> You don't have the full picture. The way it works now is minimal effort
> and is quite effective.
>
> It is a most workable and efficient solution, which nicely handles your
> stated position that you, Dave, will *only* work on -dev.
>
> David> Now the trackers have to know (a) when the latest divorce occured,
> David> (b) when the latest release was carved and (c) what's in the
> David> development branch.
>
> I'm not sure I follow or agree with what you say here, but all of the
> changes are listed in the ChangeLog, and they are quite easy to locate and
> identify.
>
> The most difficult problem is that you (Dave) often make changes where I
> cannot easily create ChangeLog notes. You sometimes describe your changes
> in an email message to hackers@, but that doesn't make it any easier for
> me to get these changes into the ChangeLog file.[/color]

Yes, this is where improvements were appreciated.

For example, see the current thread "Windows Time with NTPv4" where Dave had
already supplied a workaround back in 2002 (see the links in my post
there).

However, if you have a look at the Changelog file in ntp-dev I don't know
how to locate this or find out in which version this had been made
available. Searching the changelog for "w32time", "symmetric", "peer", or
"client" does not yield the desired result.

Since all the changelog entries are without date, it's even hard to
correlate the version numbers with the dates of the NG articles or mails on
the hackers list.
[color=blue]
> Given your desire to have the revision control system be completely
> invisible to you, at the moment the status quo is the best solution we
> have.
>
> Martin has already given me some suggestions on how to improve this,[/color]

... one of which was to include at least the release dates in the changelog.
[color=blue]
> and I
> will be following his ideas.[/color]

Great, thanks.


Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Ryan,

Ryan Malayter wrote:[color=blue]
> On Mar 6, 6:13*am, Martin Burnicki <martin.burni...@meinberg.de>
> wrote:[color=green]
>> 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?)[/color]
>
> Google has already implemented it:
>[/color]
[url]http://www.google.com/search?q=pool+site%3Alists.ntp.org%2Fpipermail%2Fhackers%2F[/url][color=blue]
>
> And Microsoft says "Me Too!":
>[/color]
[url]http://search.live.com/results.aspx?q=pool+site%3Alists.ntp.org%2Fpipermail%2Fhackers%2F&go=Search&form=QBRE[/url]

Of course I know I could use the search engines to find articles.

Anyway, the point is that you have to do some deep research to find out
things that should be clearer and more obvious, in the context of this
thread.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Danny,

The specific accusation directed to me personally was about the notrust
bit, which change I described in my previous message. I hadn't noticed
the L option change, which was not by my hand.

While I don't maintain the changelog, it would seem a simple matter to
paste my hackers announcements to the changelog.

The web documentation does make specific mention that it applies only to
the latest snapshot and advises users to see the docuemntation that came
with the version they use. A statement to that effect is prominently
displayed in the documentation home page. It could be that statement
should be more specific and that it be displayed on a [url]www.ntp.org[/url] page;
suggestions are welcomed.

Dave

Danny Mayer wrote:[color=blue]
> Martin Burnicki wrote:
>[color=green]
>>Dave,
>>
>>David L. Mills wrote:
>>[color=darkred]
>>>Martin,
>>>
>>>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?[/color]
>>
>>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.
>>
>>[color=darkred]
>>>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.[/color]
>>
>>Yes, in fact I've been referring to the notrust bit:
>>[url]http://support.ntp.org/bin/view/Support/AccessRestrictions#Section_6.5.3.1[/url].
>>
>>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."
>>
>>[color=darkred]
>>>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.[/color]
>>
>>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:
>>[url]https://lists.ntp.org/pipermail/hackers/[/url]
>>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.
>>
>>[color=darkred]
>>>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.[/color]
>>
>>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.
>>
>>Martin[/color]
>
>
> Martin,
>
> The real problem here is that as long as this is a volunteer effort it's
> hard to get someone to keep track of when a new feature is introduced or
> a bug is fixed apart from what we are doing in the Changelog. As you
> know the -stable release only changes with bug fixes and no new
> enhancements are introduced there unless the minor rev is bumped. The
> best that can be done right now is to include in Changelog whenever a
> new feature is introduced.
>
> Danny[/color]

>>> In article <fr3gfa$p$1@scrotar.nss.udel.edu>, "David L. Mills" <mills@udel.edu> writes:

David> While I don't maintain the changelog, it would seem a simple matter
David> to paste my hackers announcements to the changelog.

Dave,

The ChangeLog entries are, by design, short. Under 1 line long.

The distribution process also produces a CommitLog, which contains the
details of every commit. The CommitLog file is part of every rolled
tarball.

Since you do not use the revision control system, I commit your changes.
There are some problems with this approach:

- often your changes are part of an ongoing effort and I do not have
sufficient information (or understanding) of the intricate details of
what any given set of changes do, so I cannot easily identify exactly
changes have been made for that particular -dev release.

- your "wrap up" email usually happens after the commit, and includes
information that frequently spans a number of previous commits.

I will see what I can to do get your "wrap up" email messages added to the
CommitLog file. This will probably mean that your wrap-up changes will be
in, say the ...p123 release, and when I incorporate your "wrap up" message
there will be a ...p124 release where the only difference between p123 and
p124 is that the latter includes the CommitLog file containing your "wrap
up" notes.

With the exception of your email messages that describe your changes, all of
the information Martin has asked for is in the CommitLog file. But it can
be buried in a lot of other detail.

I'm open to suggestions on how to make improvements in this beast, and I
would prefer solutions that do not involve a "step backwards" in any areas.

--
Harlan Stenn <stenn@ntp.org>
[url]http://ntpforum.isc.org[/url] - be a member!

>>> In article <o9gfa5-9a3.ln1@gateway.py.meinberg.de>, Martin Burnicki <martin.burnicki@meinberg.de> writes:

Martin> Harlan Stenn wrote:[color=blue][color=green][color=darkred]
>>>>> In article <fqpbr5$3c2$1@scrotar.nss.udel.edu>, "David L. Mills"
>>>>> <mills@udel.edu> writes:[/color][/color][/color]

Harlan> The most difficult problem is that you (Dave) often make changes
Harlan> where I cannot easily create ChangeLog notes. You sometimes
Harlan> describe your changes in an email message to hackers@, but that
Harlan> doesn't make it any easier for me to get these changes into the
Harlan> ChangeLog file.

Martin> Yes, this is where improvements were appreciated.

Martin> For example, see the current thread "Windows Time with NTPv4" where
Martin> Dave had already supplied a workaround back in 2002 (see the links
Martin> in my post there).

Martin> However, if you have a look at the Changelog file in ntp-dev I don't
Martin> know how to locate this or find out in which version this had been
Martin> made available. Searching the changelog for "w32time", "symmetric",
Martin> "peer", or "client" does not yield the desired result.

Martin> Since all the changelog entries are without date, it's even hard to
Martin> correlate the version numbers with the dates of the NG articles or
Martin> mails on the hackers list.

Martin, at the risk of repeating what I said in a recent similar reply,
the information you seek (with the exception of Dave's email/newsgroup
postings) should already be in the CommitLog file.

The CommitLog file is automatically generated.

I'm open to suggestions on how to make it more useful.
--
Harlan Stenn <stenn@ntp.org>
[url]http://ntpforum.isc.org[/url] - be a member!

Harlan,

What you see from me is what you get. How you incorporate it in whatever
archive you maintain is at your convenience.

Dave

Harlan Stenn wrote:
[color=blue][color=green][color=darkred]
>>>>In article <fr3gfa$p$1@scrotar.nss.udel.edu>, "David L. Mills" <mills@udel.edu> writes:[/color][/color]
>
>
> David> While I don't maintain the changelog, it would seem a simple matter
> David> to paste my hackers announcements to the changelog.
>
> Dave,
>
> The ChangeLog entries are, by design, short. Under 1 line long.
>
> The distribution process also produces a CommitLog, which contains the
> details of every commit. The CommitLog file is part of every rolled
> tarball.
>
> Since you do not use the revision control system, I commit your changes.
> There are some problems with this approach:
>
> - often your changes are part of an ongoing effort and I do not have
> sufficient information (or understanding) of the intricate details of
> what any given set of changes do, so I cannot easily identify exactly
> changes have been made for that particular -dev release.
>
> - your "wrap up" email usually happens after the commit, and includes
> information that frequently spans a number of previous commits.
>
> I will see what I can to do get your "wrap up" email messages added to the
> CommitLog file. This will probably mean that your wrap-up changes will be
> in, say the ...p123 release, and when I incorporate your "wrap up" message
> there will be a ...p124 release where the only difference between p123 and
> p124 is that the latter includes the CommitLog file containing your "wrap
> up" notes.
>
> With the exception of your email messages that describe your changes, all of
> the information Martin has asked for is in the CommitLog file. But it can
> be buried in a lot of other detail.
>
> I'm open to suggestions on how to make improvements in this beast, and I
> would prefer solutions that do not involve a "step backwards" in any areas.
>[/color]

David L. Mills wrote:[color=blue]
> Danny,
>
> The specific accusation directed to me personally was about the notrust
> bit, which change I described in my previous message. I hadn't noticed
> the L option change, which was not by my hand.
>[/color]

Well it might well have been me since I have touched that code a number
of times. I'm intending to get rid of it as soon as Harlan and I have
agreement on the syntax of the changes. This will implement listen-on
and query-on directives in the configuration file to allow the admins to
have control over exactly what addresses and interfaces to use to
receive and transmit NTP packets. I already have working code for this.
We just have details to resolve.

Danny

Danny,

Understand. You guys have been wizards with the net interfaces. Real
magic. I haven't heard anybody comment on IGMP and the need to replicate
for the DVMRP spanning tree. Is that done by IGMP without NTP being
involved? If so and multiple endpoints result, Autokey would surely scream.

You may notice in the fog of war that Autokey names potentially can
replace the IP addresses. Need to work on that...

Dave

Danny Mayer wrote:[color=blue]
> David L. Mills wrote:
>[color=green]
>>Danny,
>>
>>The specific accusation directed to me personally was about the notrust
>>bit, which change I described in my previous message. I hadn't noticed
>>the L option change, which was not by my hand.
>>[/color]
>
>
> Well it might well have been me since I have touched that code a number
> of times. I'm intending to get rid of it as soon as Harlan and I have
> agreement on the syntax of the changes. This will implement listen-on
> and query-on directives in the configuration file to allow the admins to
> have control over exactly what addresses and interfaces to use to
> receive and transmit NTP packets. I already have working code for this.
> We just have details to resolve.
>
> Danny[/color]

Harlan Stenn wrote:[color=blue]
> Martin, at the risk of repeating what I said in a recent similar reply,
> the information you seek (with the exception of Dave's email/newsgroup
> postings) should already be in the CommitLog file.[/color]

... which doesn't make it easier for non-developers to find out whether a
specific version supports a specific feature.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Dave,

No I haven't thought about IGMP. NTP is only involved in the sense that
it sends an IGMP message to the router notifying it of it's request to
receive multicast messages with a given IP address. It has no other
interaction with IGMP. It's then the router's responsibility to forward
messages with that IP address to the wire on which the multicast
requestor resides.

I do not see how this would affect autokey since autokey is done on a
one-to-one basis by specific (non-multicast) address. The multicast
address is not involved in autokey.

I'm not sure what you mean by an autokey name. It's not even clear to me
how you would ensure uniqueness of the name. I am, however, interested.

Danny

David L. Mills wrote:[color=blue]
> Danny,
>
> Understand. You guys have been wizards with the net interfaces. Real
> magic. I haven't heard anybody comment on IGMP and the need to replicate
> for the DVMRP spanning tree. Is that done by IGMP without NTP being
> involved? If so and multiple endpoints result, Autokey would surely scream.
>
> You may notice in the fog of war that Autokey names potentially can
> replace the IP addresses. Need to work on that...
>
> Dave
>
> Danny Mayer wrote:[color=green]
>> David L. Mills wrote:
>>[color=darkred]
>>> Danny,
>>>
>>> The specific accusation directed to me personally was about the notrust
>>> bit, which change I described in my previous message. I hadn't noticed
>>> the L option change, which was not by my hand.
>>>[/color]
>>
>> Well it might well have been me since I have touched that code a number
>> of times. I'm intending to get rid of it as soon as Harlan and I have
>> agreement on the syntax of the changes. This will implement listen-on
>> and query-on directives in the configuration file to allow the admins to
>> have control over exactly what addresses and interfaces to use to
>> receive and transmit NTP packets. I already have working code for this.
>> We just have details to resolve.
>>
>> Danny[/color]
>
> _______________________________________________
> questions mailing list
> [email]questions@lists.ntp.org[/email]
> [url]https://lists.ntp.org/mailman/listinfo/questions[/url]
>
>[/color]