Recent trends in the codebase size

[Mark Atwood]

Kill it

On Sun, Jan 29, 2017 at 9:05 PM Eric S. Raymond <esr at thyrsus.com> wrote:

> Mark Atwood <fallenpegasus at gmail.com>:
> > Is there a reason to keep dumbclock?   Maybe it exists as a starting
> > framework for when someone wants to write a new clockdriver?
>
> Actually, I only left dumbclock in because you said "keep it for the lulz"
> during the conversation about some other refclock that we ended up
> dropping.
>
> You've put your finger on the only even weakly persuasive argument for
> keeping it.  But:
>
> 1. If we want a simple model for an old-school refclock, a couple
> others are handy.  The most obvious is refclock_local.c; zyfer and
> spectracom would also be good. In fact the spectracom driver (under
> its old WWVB or "Type 4" name) historically *was* the model for several
> other drivers - it's often cited in header comments.
>
> 2. If it were up to me, nobody would ever write an old-school refclock
> again.  Makes more sense to write a parse template for the generic
> driver.  You get more code re-use that way.
>
> So no, I don't see remaininh value in keeping it.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170130/73bbac99/attachment.html>