[Pool] Off by a second leap second failures
martin.burnicki at burnicki.net
Sun Jul 12 08:01:56 UTC 2015
Harlan Stenn wrote:
> Hal Murray writes:
>> stenn at ntp.org said:
>>> There has currently been no discusison about how often point patches
>>> should be released.
>> My 2 cents...
>> Patch releases should be reserved for bug fixes. They should be drop
>> in replacements with no user visible changes. (User in that context
>> means sysadmin.)
>> Of course, there are exceptions. I think the recent smear option is a
>> good example. Normally, I'd expect new features to be part of the
>> next stable release. If you don't have enough time to thoroughly test
>> all the other changes, then a patch release might make sense.
I fully agree. While the new smear option provides a new feature this
feature alone would not be a good reason for a new -stable release.
Beside this the new feature is optional, so users who explicitly want
this can use it, but the behaviour of existing
installations/configurations is left unchanged it ntpd is just upgraded
to this patch release.
>>> You may also note that 4.2.8 is getting more frequent patch releases.
>>> Some people really like that. Some people really dislike it. I'd
>>> like to see a stable release every year or so.
I'd like to see a new stable release when there's something really new
in the code, not even because it has been a year since the last one, and
bugs which have been discovered have already been fixed in patch releases.
>> Do the people who want more frequent patch releases really want patch
>> releases or more frequent stable releases? What do they want in their
>> newer releases? Would they be happy if you just announced an
>> occasional -dev release as a good one?
> Security issues change everything. It's my preference to not mix
> security updates with other updates. Sometimes that works out well,
> sometimes not.
IMO it's no problem if a security update also contains other bug fixes.
If a security update has to be rolled out, and there are other bug fixes
already ready in the wait queue for a patch release, then why not?
> One big company told me: We'd rather there were no security issues,
Hm, I don't think there's someone out there who preferred that there
were security bug, maybe except the NSA and friends. Unfortunately those
bugs are usually just unintentionally. ;-)
> If a security issue happens, we'd like as much notice as
> possible, as soon as possible. As far as a feature release goes, it
> takes us a good 6 months' time to check those out, so we'd rather they
> never happened either, because they take time and money.
Right, but if there are already fixes for other bug in the code base,
why shouldn't they be included when a new patch release is rolled out
due to a security fix?
> I've had folks tell me that they think that the only things that should
> go into a patch release are bugfixes, no enhancements, and that we
> should never knowingly break backward compatibility in a patch release.
> Usually we can do this. Usually.
Yes, and the most important thing is about backward compatibility, IMO,
especially when we are talking about security fixes which need to be
rolled out quickly, without giving OS vendors/maintainers a chance to
run extensive tests with a new version.
> I'm not seeing a good reason to delay enhancements until the next major
> release. This would mean stuff like the 'apeers' command in ntpq would
> either not come out for a while, or we'd have released 4.2.8 over the
> winter and released 4.4.0 this spring. Was the leap second reporting
> stuff fixed in bug 2846 a bugfix or a feature?
IMO it's a feature which doesn't really affect the usual behaviour of
If real NTP clients happened to do a polling during the leap second and
the time offset was significantly different than at previous pollings
then ntpd would have discarded this result anyway in its filter. If the
server claims to be unsynchronized during this single polling then the
result is not accepted. So in fact it makes no difference for real NTP
On the other hand, there are many SNTP client implementations out there
which just poll once and then adjust the time. Such clients could get
the time wrong if they happen to poll *during* the leap second. If they
receive an "unsynchronized", though, there's a good chance that they
discard those polling results, and at the next polling everything is
So IMO from ntpd's point of view this is just an improvement which helps
dumb clients to behave more smoothly.
Beside this, eventually calling the issue tracker "*bug*zilla" and
calling every single issue a "bug" even if it's actually a feature
request or enhancement is somewhat misleading, but I think we have to
live with it and just keep this in mind. ;-)
More information about the pool