e...@thyrsus.com said: > Well, normally it would be a longer freeze, but we're doing this to roll out > a bug fix on code that has been pretty stable.
Your version of "pretty stable" doesn't match mine. You want to make a point release to push out a one line patch. You are dragging along all the other changes since 1.0. Sure, we don't know of problems, but there have been lots of opportunities for seemingly innocent edits to break something. Your removal of HAVE_KERNEL_PLL is a good example. You could easily have made a typo that didn't break builds. It's only had a few days of testing. Another good example: A few days before 1.0, you edited all the msyslog messages to have a TAG: on the front of the text. Sure, it didn't actual break anything, but you didn't leave much time for fixing typos and there were several of them. That sort of thing looks sloppy to me. It reminds me that we haven't taken time to test things. It may have been a good idea, but wasn't appropriate if we were trying to get a release ready. The MODE6 stuff is crap. This has nothing to do with mode 6 packets: 5 Dec 01:19:58 ntpd[595]: MODE6: 192.168.1.22 8014 84 reachable 5 Dec 02:17:52 ntpd[595]: MODE6: 192.168.1.19 944a 8a sys_peer 5 Dec 02:29:18 ntpd[595]: MODE6: 192.168.1.33 904a 8a sys_peer 5 Dec 13:22:25 ntpd[595]: MODE6: 192.168.1.20 8013 83 unreachable 5 Dec 14:37:06 ntpd[595]: MODE6: 192.168.1.94 8013 83 unreachable 5 Dec 15:17:07 ntpd[595]: MODE6: 192.168.1.94 8014 84 reachable ----------- What would you do if the world wasn't "pretty stable"? Should we have the technology to release branches? Is this a good opportunity to test/debug that? I'd vote for including my fix to ntpq direct mode for mrulist. It will take manual intervention. I had to fix the test program too. I put them in the same commit to avoid breaking HEAD, but the test program wasn't part of 1.0. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
