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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel