Re: Time to plan for 1.0

Hal Murray : > >> ntpq fails too often on flaky links. I seem to be the only one > >> who notices it. > >> I assume it's something in the retransmission logic. > > > Are all these sentences describing one problem, or is there a > > bug *other* than failed retransmission

Testing, 1.0, startup time

One of the things we need to verify is that our code starts as fast as ntp clsssic. I think they get going in 11 seconds. It's on their web someplace. I don't know how to easily automate that. A hack to scan log files might help. This may be the tip of an iceberg, but I can't think of any

Re: Time to plan for 1.0

>> ntpq fails too often on flaky links. I seem to be the only one >> who notices it. >> I assume it's something in the retransmission logic. > Are all these sentences describing one problem, or is there a > bug *other* than failed retransmission on flaky links? I'm not sure what you are

Re: Time to plan for 1.0

> I was trying to verify that the bug number referred to > the same problem as the rest of your text description. I expect there is a bug matching what I described, but I'm not sure and I'm not in a position to search or it. -- These are my opinions. I hate spam.

Re: Time to plan for 1.0

Yo Ian! On Tue, 8 Aug 2017 08:36:55 -0500 Ian Bruene via devel wrote: > Oh, and I can confirm that the code in agentx.py (also ntpsnmpd but I > haven't merged that) is completely separate from everything else. > > agentx.py can be ripped out for 1.0 without problems, it

Re: Time to plan for 1.0

Hal Murray : > > There is one bug that I think should get fixed. I don't know the number. > > ntpq fails too often on flaky links. I seem to be the only one who notices > it. > > I assume it's something in the retransmission logic. Are all these sentences

Re: Time to plan for 1.0

This morning on #ntpsec: 07:45 <@esr> ianbruene: I knew the snmpd project would lead to much yak shaving. This is actually part of the reason I viewed it it as a good training opportunity. When you're not under time pressure and can thus afford to get

Re: Time to plan for 1.0

Oh, and I can confirm that the code in agentx.py (also ntpsnmpd but I haven't merged that) is completely separate from everything else. agentx.py can be ripped out for 1.0 without problems, it could be shipped in a perfectly broken state without problems outside of being /incredibly/ bad

Re: Time to plan for 1.0

Ian Bruene via devel : > > Oh, and I can confirm that the code in agentx.py (also ntpsnmpd but I > haven't merged that) is completely separate from everything else. > > agentx.py can be ripped out for 1.0 without problems, it could be shipped in > a perfectly broken state

Re: Time to plan for 1.0

Ian Bruene via devel : > I was already on the verge of calling it, given the above I am now > Officially Calling SNMP support as slipping past 1.0. Strictly speaking you can't do that. It's the PM's decision whether we want to drop the feature or change the schedule. We're

Re: Time to plan for 1.0

On 08/08/2017 09:01 AM, Eric S. Raymond wrote: Strictly speaking you can't do that. It's the PM's decision whether we want to drop the feature or change the schedule. We're pretty informal here, but you need to know where those lines of authority are, because many other projects (especially

Re: Time to plan for 1.0

On 08/08/2017 11:16 AM, Eric S. Raymond wrote: Thank you, that is correct procedure. Acting in Mark's absence I concur; we'll slip it if you don't have it done. Mark has the privilege to override this decision but I will be quite surprised if he does. Well now I'm increasing this to

Re: Time to plan for 1.0

Ian Bruene : > Well now I'm increasing this to Official /Strong/ Suggestion: the packet.py > testing project just got moved to the top of the list because of bug #341. > And IIRC the code in packet.py is entangled with the comm channels in ways > that may require a significant

Re: Time to plan for 1.0

Ian Bruene : > On 08/08/2017 09:01 AM, Eric S. Raymond wrote: > >Strictly speaking you can't do that. It's the PM's decision whether > >we want to drop the feature or change the schedule. We're pretty informal > >here, but you need to know where those lines of authority are,