Yo Ian!
On Wed, 9 Aug 2017 06:34:17 -0500
Ian Bruene via devel wrote:
> On 08/09/2017 01:13 AM, Gary E. Miller via devel wrote:
> > I find leaving ntpmon running is smoking out a bunch of hard
> > failure.
>
> In hindsight (yeah) we should have thought of this
We did, issue #341 is two month
On 08/09/2017 01:13 AM, Gary E. Miller via devel wrote:
I find leaving ntpmon running is smoking out a bunch of hard failure.
In hindsight (yeah) we should have thought of this - *I* should have
thought of this - a long time ago.
--
In the end; what separates a Man, from a Slave? Money? Po
Yo Hal!
On Tue, 08 Aug 2017 21:54:36 -0700
Hal Murray via devel wrote:
> >> 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
> > b
> 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.
___
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 on flaky links?
>
> I'm
>> 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 asking.
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 could be
> shipped in
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 test jig, or refactor
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 Officia
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, because
> >many other
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 i
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 without problems outside
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 pretty informal
here,
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 for
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 th
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 describing one problem, or is there
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.
--
These are my opinions. I hate spam.
__
Gary E. Miller :
> > Gary, Hal, Matt, Daniel: Would all of you check in on this, please?
>
> Done.
Good. Please confirm that you're not identifying any potential blockers
other than #341.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Please consider contributing to my Patreon p
Gary E. Miller via devel :
> Yo Ian!
>
> On Mon, 7 Aug 2017 15:04:34 -0500
> Ian Bruene via devel wrote:
>
> > Only thing I know of is bug #341, which I have repeatedly forgot or
> > deliberately ignored because other things were higher priority. *If*
> > the bug still even exists, as I have hea
Daniel Franke :
> If we're aiming for a September 28 release then I propose we should
> have a dev freeze by September 1. Bug fixes only during that month;
> anything that's mere polishing goes on a branch.
>
> I don't want to release 1.0 without having
> https://tools.ietf.org/html/draft-ietf-ntp
Sorry I missed the meeting. I understand why distro maintainers
wouldn't want pre-1.0 code. I thought that you would release 1.0 both
as the usual source repo _and_ with "example" packages. I would expect
that the maintainers might well repackage to suit their tastes.
On 08/07/2017 03:59 PM,
Yo Ian!
On Mon, 7 Aug 2017 15:04:34 -0500
Ian Bruene via devel wrote:
> Only thing I know of is bug #341, which I have repeatedly forgot or
> deliberately ignored because other things were higher priority. *If*
> the bug still even exists, as I have heard nothing about it since
> back when it wa
Note to self: check the reply address in the future.
Forwarded Message
Subject:Re: Time to plan for 1.0
Date: Mon, 7 Aug 2017 14:59:14 -0500
From: Ian Bruene
To: Eric S. Raymond
On 08/07/2017 11:58 AM, Eric S. Raymond via devel wrote:
If anyone thinks my
Yo Eric!
On Mon, 7 Aug 2017 15:51:13 -0400
"Eric S. Raymond via devel" wrote:
> John D. Bell :
> >
> > I thought that one necessity before 1.0 were at least preliminary
> > "packaged" version for the major distros - i.e., .deb and .rpm
> > files, conformant to the conventions (file locations, e
John D. Bell :
>
> I thought that one necessity before 1.0 were at least preliminary
> "packaged" version for the major distros - i.e., .deb and .rpm files,
> conformant to the conventions (file locations, etc.) of the systems that
> used them.
>
> Am I wrong? If not, do you know what the status
I thought that one necessity before 1.0 were at least preliminary
"packaged" version for the major distros - i.e., .deb and .rpm files,
conformant to the conventions (file locations, etc.) of the systems that
used them.
Am I wrong? If not, do you know what the status of these are?
On 08/07/201
Yo Daniel!
On Mon, 7 Aug 2017 13:18:14 -0400
Daniel Franke via devel wrote:
> I don't want to release 1.0 without having
> https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-01
> implemented. As of the last IETF meeting I'm confident that there
> aren't going to be any significant norm
If we're aiming for a September 28 release then I propose we should
have a dev freeze by September 1. Bug fixes only during that month;
anything that's mere polishing goes on a branch.
I don't want to release 1.0 without having
https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-01
implem
Yo Eric!
On Mon, 7 Aug 2017 12:58:13 -0400 (EDT)
"Eric S. Raymond via devel" wrote:
> * We need to start working towards a 1.0 release no later than 28
> September.
Very doable, good plan to do so.
> If anyone thinks my assumptions are incorrect, speak up quickly,
> please.
I'm 100% with you
29 matches
Mail list logo
