Upcoming feature freeze

[Sanjeev Gupta]

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 at 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 at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170823/66fde97e/attachment.html>