Re: prep for 1.0.1

devel@ntpsec.org said: > So, I'm declaring an intention for the 1.0.1 release the weekend after next, > about March 3rd. Could you please say a bit more about how you picked that date? I would expect either: as soon as we finish feature X, or as soon as we stop fixing minor things (like

Future projects (post release)

There are two projects I've had my eye on for a while. The first is to remove the input buffer queue. That's leftover from before kernels supported time stamps on received network packets. (ntpd used to grab the packets from an IO signal handler) The other is to remove the table lookup in

Re: Should we just remove the broadcast option?

devel@ntpsec.org said: > Your first 'graph is something I didn't know. I think it removes the > pressure to keep this feature. Go ahead and take it out, Hal. OK. I'll take it out of the parser in time for the release. Cleaning up the internals should wait until after the release. --

Re: prep for 1.0.1

> The big deal is whether we have closure on the Python installation mess. The only loose end that I know about is PYTHONDIR vs PYTHONARCHDIR. We now understand why what we have been expecting doesn't work. We are trying to import ntp.ntpc. That's a two step process. First it looks up ntp,

Re: Should we just remove the broadcast option?

Mark Atwood : > I think all modern Windows machines get their address from their domain > controller, or from ntp?.microsoft.com > > If its a snarl, Im tending towards removing it, and documenting it's > absence. Mark, it is kind of a snarl. Not so much the incremental

Re: Should we just remove the broadcast option?

On Wed, Feb 21, 2018 at 03:25:52AM +, Mark Atwood via devel wrote: > I think all modern Windows machines get their address from their domain > controller, or from ntp?.microsoft.com Per

Re: prep for 1.0.1

On 02/20/2018 08:41 PM, Mark Atwood via devel wrote: Hi! A few months ago, I announced prep for a 1.0.1 release. Turns out, it never actually happened. So, I'm declaring an intention for the 1.0.1 release the weekend after next, about March 3rd. As you work, consider stability, and avoid

Re: prep for 1.0.1

On 02/20/2018 09:19 PM, Eric S. Raymond via devel wrote: I'll get on the tracker and swat a bunch of small issues I see. The big deal is whether we have closure on the Python installation mess. The Python installation works the way it did before that last minute 'fix' before 1.0. So the

Re: Should we just remove the broadcast option?

I think all modern Windows machines get their address from their domain controller, or from ntp?.microsoft.com If its a snarl, Im tending towards removing it, and documenting it's absence. On Tue, Feb 20, 2018 at 5:16 PM Eric S. Raymond via devel wrote: > Mark! Heads

Re: prep for 1.0.1

Mark Atwood via devel : > A few months ago, I announced prep for a 1.0.1 release. Turns out, it never > actually happened. > > So, I'm declaring an intention for the 1.0.1 release the weekend after next, > about March 3rd. > > As you work, consider stability, and avoid

prep for 1.0.1

Hi! A few months ago, I announced prep for a 1.0.1 release. Turns out, it never actually happened. So, I'm declaring an intention for the 1.0.1 release the weekend after next, about March 3rd. As you work, consider stability, and avoid introducing instability. And let us know if it

Re: Should we just remove the broadcast option?

Mark! Heads up...exernal/marketing issue incoming. Hal Murray via devel : > Is anybody using/testing it? Not as far as I know > We don't support receiving broadcast. No, I removed that after Daniel explained that it's unsecurable. > It used to support a ttl option. That

Should we just remove the broadcast option?

Is anybody using/testing it? We don't support receiving broadcast. It used to support a ttl option. That got broken/dropped somewhere along the way. Should I restore that? Or maybe document that it is missing? ... Context is that I'm cleaning up the mode/ttl mess. The mode for refclocks