Harlan Stenn wrote: > Hal Murray writes: >> >> [email protected] 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, > ever. 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 NTP installations/networks. 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 clients. 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 fine again. 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. ;-) Martin _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
