Recent trends in the codebase size

[Eric S. Raymond]

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>