Jason Azze via devel <devel@ntpsec.org>: > I predict that ESR will ask me for an alternative approach. He won't > like my recommendation. It's to use a feature or development branch > for a change as big as the introduction of NTS.
Even if I liked using feature branches (and I don't; see https://blog.ntpsec.org/2017/04/09/single-head-provable-steps.html for explanation) they wouldn't solve our actual problem. NTS isn't an experiment that may or may not be merged at some point in the indefinite future, it is our main line of development because Cisco has promised us money to have it ready to ship in our next point release. Thus, putting the work on a branch would be pointless. This is also the reason I haven't made an NTS config option. The only theoretical justification would be giving people who build from source the option of avoiding the increase in code footprint from NTS support. But when you start asking who actually might *want* that... It's no help to distro packagers, who are going to want to compile in maximum features rather than a minimal build. Actually, the additional code volume for support of NTS is so low that it's difficult to see it being a problenm for *anyone*, especially when bear in mind that NTP Classic users put up with code 4:1 larger. A branch or config conditional would also have costs in test complexity that I don't care to incur. In every scenario I've gamed out in my head, the right answer comes out the same: Keep It Simple, Stupid! One line of development, no new code conditional, power through the integration problem somehow. You've changed my agenda for the day. I think now I have to revisit an approach I was avoiding: including libaes_siv as a git submodule. I can male it work, but submodules are fluky and irritating. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
