Hi, I would dearly love to see #204 (/etc/ntp.d) be included in 1.0.
As a SysAdm, I typically read the new features list rarely. If it does not land in 1.0 (and pacakge managers and I do not start using it then), it may never get used. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane On Wed, Aug 23, 2017 at 10:07 PM, Eric S. Raymond via devel < devel@ntpsec.org> wrote: > Our planned ship date for 1.0 is 28 September. > > We'll feature-freeze sooner than that - not sure when yet but > somewhere in the ballpark of 7-14 September seems likely. > > We're down to 7 issues on the tracker. Feature freeze has > implications for the two that are RFEs, and for one other. > Here they are: > > #251: Add fudge option to server config > > If this is going to happen in 1.0. somebody needs to land a patch > before feature freeze. That someone should be equipped to test the > patch - e.g. not me, as I don't have significant asymmetric delay > to contend with. > > If someone steps up, though, I will write the scanner/parser end to > get that offset number into the peer structure. It's not reasonable > to expect anyone else but me to grapple with *that* part of the code. > > Remember, documentation patches *are* required when you add a feature > > As this would be a pure feature addition, there's no issue with > allowing it to wait until 1.1. > > #204: Support /etc/ntp.d > > This feature is working, and documented - has been for more than 6 > months. For pretty obvious reasons, we should not go breaking > backward compatibility after 1.0. > > That means the window during which we can change the behavior is > getting pretty short. Anybody who wants this has two to three > weeks, at the outside, to make the argument and ship the code. > > When I say "make the argument" I mean that I want to see a concrete > design and an explanation of why it solves all the problems this one > does, and one or more additional ones. Merely not liking it the way > it is insufficient. > > #55: ntpd refclock GPSD_JSON just stops working. > > I am unhappy with this driver. I believe - as this bug demonstrates - > that it's too crappy to ship if we want to establish and maintain a > reputation for trouble-free operation. > > It's an unusual case - the feature that brings it closest to working > right is marked experimental, and it's redundant with the SHM driver > because GPSD feeds the SHM driver quite happily. In fact, the JSON > parsing overhead means the latency and jitter of this driver is > necessarily inferior to delivery via SHM. > > Thus, I think the best thing to do about it would be do simply delete it > and shed the defect exposure, redirecting users to GPSD+SHM. And > if that going to happen, it needs to happen *now* - that is, before > 1.0 implies a promise that it will be stable and maintained. > > If any of you have an interest in saving this driver, step up now > and fix it. > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> > > "As to the species of exercise, I advise the gun. While this gives [only] > moderate exercise to the body, it gives boldness, enterprise, and > independence > to the mind. Games played with the ball and others of that nature, are too > violent for the body and stamp no character on the mind. Let your gun, > therefore, be the constant companion to your walks." > -- Thomas Jefferson, writing to his teenaged nephew. > _______________________________________________ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
