We're down to 5 issues on the tracker, 4 not counting a completed RFE.
That's a good feeling this far in advance of our release date.
We now have an NTPsec instance providing pool service under heavy load, in
Austria. That's what smoked out the mystery crash; since then it's
been running stable and our beta tester is happy. This was an
important check; it's one thing to know that our ntpd works well on a
low-traffic desktop client setup, entirely another to be sure it can
take hundreds of requests a minute in stride.
That same tester has been sending us a steady stream of small bug
reports, mostly around ntpq, that have helped us polish and improve
it quite a lot. This has also turned up weaknesses in the
documentation, which is stronger as a result.
The new 'bias' config keyword will probably the last new feature
before we ship. There's actually more to the machinery behind it
than meets the eye; I'm going to explain that here because it might
matter past 1.0 when we think about adding new config elents to
support (say) NTS.
As I began looking at implementing 'bias' I became disturbed by what
I found in the data path from server config declarations down to the
newpeer() call that sets up a peer association. The config parser
naturally packs the decalration payload into a struct, but the
struct was then unpacked an the payjoad passed to newpeer() as
multiple argument variables.
This way of doing things made adding new config options a defect-prone
process. Basically, the argument signature of newpeer() had to change
every time; it featured an unreasonably large and increasing number
of arguments.
No more. Now the config block is passed down to newpeer(), which
copies it to a permanent home in the new peer block (after
sanity-checking some members).
Following this change, adding 'bias' was trivial. (1) add a 'bias'
member in the config block, (2) make the YACC grammar fill it in
(a thing I could do in my sleep), and (3) notice that the value is
available in the new peer block after config and do whatever with it.
The time and expected additional defect exposure associating with
adding more options is now really, really low. This doesn't mean we
should go nuts adding marginal ones, but it does give us a bit freer
hand on the design level.
Finally, I think it is also significant what kinds of bug reports we
have *not* been getting. It's hard to notice an absence, so I want
you all to take a moment to notice how infrequent, minor, and
superficial our problem reports have been. That's an achievement in
code that has been shrunk by 75%, heavily refactored, and part
rewritten in a different language.
Once again, I think this is performance for the whole team to be
proud of. Yes, I've been the lead surgeon for the heaviest C work,
but the team's support has been magnificent and maybe I have
not appreciated that as loudly as I should. Fred Brooks was
right - surgical teams *work*, and they fly not just on the
capability of the lead but on the ability of senior assistants
and the junior associates learning by example. I'm no longer
even surprised when all of you perform exceptionally well.
Let us now hope the next 18 days are boring and we can fuck
off a lot. Because that's predicts a really solid release.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
