My pre-1.0 wishlist

Daniel Franke dfoxfranke at gmail.com
Fri Jun 3 22:06:46 UTC 2016


There's been some chatter on this list lately about whether we're
ready for a 1.0 release. My opinion is "not yet". Here is my wishlist
for things that I want us to get done before we go to 1.0, in rough
order of decreasing importance.

1. End-to-end test automation

While many of us having been regularly exercising NTPsec and
witnessing excellent stability, I suspect that there are a great many
obscure features that nobody is testing and I worry that some of these
have bitrotted. What was the last time anybody tried out symmetric
interleaved mode? Orphan mode? Pool mode? The huff'n'puff filter? We
need automation that covers this stuff and keeps us from shipping
broken releases. And if some feature is too obscure or useless to put
the energy into automating it, we should rip it out.

2. Better process and communication around vulnerabilities inherited
from NTP Classic

We were slow in getting vuln fixes from ntp-4.2.8p7 into NTPsec
because we got blindsided by so many of them. This time around with
4.2.8p8 we did far better, but I want us to mature to the point where
our release announcements can be simultaneous. Part of this will have
to involve improving our internal communication and release
engineering and the other part will have to involve better
collaboration with NTP.org. I know exactly how problematic the
politics are around the latter, but we have got to find a way to make
it happen. When we start pushing for broader NTPsec adoption, the rest
of the world isn't going to care about our political squabbles.
They're going to care that NTP Classic fixed a critical vulnerability
N hours ago, and that there is no patch yet for NTPsec.

3. All roadmapped featurectomies

The more users we have, the more loudly people are going to complain
about any features we remove. At our F2F we committed to eventually
removing saveconfig and client-side broadcast mode. We shouldn't
release 1.0 before we've completed that work, and furthermore we
should look around and decide what *else* we don't want to commit to
supporting for years to come.

4. Any planned backward-incompatible changes to the configuration language

We've been talking for a long time about replacing the 'restrict'
directive and all the language around what keys have what
authorizations with something sane. We should get this done before
1.0.

5. Formal processes around code review

Last year we looked at Phabricator and decided that for the time being
it was too much of an obstacle for our development pace. I think that
was the right call at the time, but eventually I want to revisit this.
We don't have to choose that tool in particular, but if we're still
moving too quickly for a merge-based workflow with code-reviewer
sign-off before every master commit to be practical, then we're also
not yet stable enough for 1.0.

6. An NTP Classic -> NTPsec migration guide

Documenting all incompatible changes since the fork.


More information about the devel mailing list