Backward-compatibility of ntpq may be an issue

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> Poor choice of words on my part.  It's really a bug fix.  Cleaning up the 
> code is just fortunate.
> 
> There are two problems in this area.  One is that there isn't any 
> documentation on what peers get skipped or why you would want to skip them or 
> that there are alternative commands that do what you might prefer.  The other 
> is that the group culture says "ntpq -p" and never mentions that some 
> important info might get skipped or that there is an alternative.

*Ouch.* I see both of your points there, I do.

> Under normal circumstances, nothing gets skipped.  I have a hacked version of 
> the old ntpq that prints out a would-get-skipped message and then prints it 
> anyway.  It goes off during startup on pool slots.  I don't know the details 
> - I'd have to look at the code.
> 
> Perhaps I'm oversensitive to this area since I wasted a lot of time when 
> debugging early pool stuff because the slots I was trying to track down 
> didn't get printed out.  I never did figure out a good reason for skipping 
> some slots or a good description for which slots get skipped.

No, I don't think you're being oversensitive at all.  You got burned
by careless UI design and poor documentation, and the way it happened
is a good argument for not leaving things as they were.

> Alternatives would be to remember if any slots were skipped and print out a 
> warning message.  Or find a place to add a flag in the printout to indicate 
> that a slot would have been skipped.  Or add a command to revert to the old 
> behavior.  Or...  But those changes might break scripts too.

Indeed they might, at least as probably as your change.

You have persuaded me that ntpq was misdesigned in this respect, and
that leaves us with no conservative alternative that doesn't suck
pretty badly.

That is sort of liberating, actually.  That means we can really clean things
up and leave a sentence or two of explanation in the Compatibility section
that should get us off the hook with the grognards.

See, what really worries me in terms of spending our tolerance budget is
changes that will seem like we were messing with things just to put a
territorial mark on them, or plain not *thinking* about backwards
compatibility.  If we supply good rationales of the form "it was
actually busted before" we draw a lot of the sting, and in this case
you've done a good job of that.

So we keep your change, and we document the reason for it, and we
fix the documentation of the commands that have changed behavior

The only question in my mind is whether or not we should declutter the
UI by removing the lassociations and lpeers commands that are now
redundant.  Do you have an opinion about this?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>