Re: prep for 1.0.1

Thanks for the input. > I'm a big fan of "always stable master" and time based releases. I'd be happy with that. What sort of interval did you have in mind for "time based"? Our master is generally pretty stable, but we don't have a solid test setup. We can tell if it builds, but that

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. I'd like to suggest the following: 1) Move #55 out of 1.0.0 milestone. 2) Close the 0.9.4, 0.9.5, and 1.0 release milestones, since those releases have already happened. 3)

Re: prep for 1.0.1

On 02/21/2018 02:44 AM, Hal Murray wrote: >> I'm a big fan of "always stable master" and time based releases. > > I'd be happy with that. What sort of interval did you have in mind for "time > based"? I don't have one in mind. Looking at the history of releases, they tend to be 1-4 months,

Testing via pool

> Two of my servers are in the NTP pool... You can get some interesting data if you kick up the memory for the MRU list. A US/NA server needs 325K to hold everything for a bit over a day. Something like: # 88200 = 86400 + 30*60 mru initmem 10 maxmem 50 maxage 88200 minage 3600

Re: prep for 1.0.1

On 02/21/2018 01:50 AM, Hal Murray via devel wrote: > 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? Please consider this my "vote"/request/preference

Re: Future projects (post release)

Those both sound like good ideas. ..m On Tue, Feb 20, 2018 at 10:03 PM Hal Murray via devel wrote: > > 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

Re: Testing via pool

hmur...@megapathdsl.net said: > You can get some interesting data if you kick up the memory for the MRU > list. > A US/NA server needs 325K to hold everything for a bit over a day. Argh. I forgot a key piece of info. That's on a box signed up for 100 megabits of IPv4 and IPv6. -- These

Re: blog | ACTION REQUIRED: Verification failed for GitLab Pages domain 'blog.ntpsec.org'

Yo GitLab! WTF? It was verified YESTERDAY, in your ticket #226, by your support guy "Lyle Kozloff (GitLab Support)" On Wed, 21 Feb 2018 14:58:48 + GitLab wrote: > Verification has failed for one of your GitLab Pages custom domains! >

Re: Future projects (post release)

Future project: refactoring ntpd's system variables into a struct. I've been looking at the code around mode 6 generation and discovered that in some areas it's still globals all the way down. Translating these globals will make future refactoring/translating easier. -- /"In the end; what

Re: Future projects (post release)

Mark Atwood via devel : > Those both sound like good ideas. ..m > > On Tue, Feb 20, 2018 at 10:03 PM Hal Murray via devel > wrote: > > > > > There are two projects I've had my eye on for a while. > > > > The first is to remove the input buffer queue. That's

Re: Future projects (post release)

Ian Bruene via devel : > > Future project: refactoring ntpd's system variables into a struct. > > I've been looking at the code around mode 6 generation and discovered that > in some areas it's still globals all the way down. Translating these globals > will make future

Re: Future projects (post release)

> I've been looking at the code around mode 6 generation and discovered that > in some areas it's still globals all the way down. Translating these > globals will make future refactoring/translating easier. I'm missing the big idea. The current case is that we have a lot of global variables.

More Security Foolishness at GitLab

Yo Security! Why are you sending secutity related email from an email that does not exist?? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588

Re: prep for 1.0.1

rlaa...@wiktel.com said: > If you're going to move to time-based, you might consider quarterly > releases? I'd be happy with quarterly releases. The next question is how seriously do we take the release date? I think there are two approaches. The first is to try hard to release as scheduled.