Upcoming feature freeze

[Eric S. Raymond]

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.