Backward-compatibility of ntpq may be an issue

[Hal Murray]

esr at thyrsus.com said:
> Hal, I was reviewing some recent changes, and it occurred to me that your
> commit changing the default of showall in ntpq may have not been a good
> idea.

> I don't think the showall functional change in either ntpmon or ntpq was a
> bad thing in itself.  But backwards-incompatible changes that might affect
> scripting worry me some. I think of the NTP userbase as very conservative
> and likely to get upset if "ntpq peers" in a pipeline does not have stable
> behavior. 

...

Yes.

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.

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.

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.



-- 
These are my opinions.  I hate spam.