prep for NTPsec 0.9.6 release

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> > If you you any reason not to tag and release 0.9.6 in the next few days,
> > please let us know. 
> 
> I think it needs a lot of testing and bug fixing and polishing rather than 
> new features that end up breaking something.
> 
> A few days is New Years.  I don't think it will get enough testing and or 
> fixing between now and then.

Enough testing and fixing for what?  The things you list are annoying,
but they're not showstoppers for a minor point release. Especially not
since we fat-fingered the last two point releases (there is now check
machinery to make sure that doesn't happen again) and we need to give
the packagers something to play with.

> There are bugs in the ntpq retransmission logic.  It's next on my list.  But 
> I keep getting sidetracked by minor things.

That is Mode 6.  The world won't end if that glitches on lessy networks;
99.9% of the plausible use cases are to localhost or a wired LAN.

> waf distclean still leaves stuff.

I'm sorry.  I've tried to fix that.  I can't; it needs a waf change.

The problem is that waf does not treat all of its special build targets
(build, install, clean, distclean) symmetrically.  Some will take a
add_post_fun() call to add a hook after the main body of the action,
some won't. Some call the main build() method, some don't.  There isn't
*any* way to post-hook distclean.

I've bitched to the author about this.  Had to explain the concept
of "orthogonality violation" to him.  I think he got it, but he
says it's a flag-day change that can't happen until the next *major*
release.

> waf build doesn't make some of the python stuff.  waf check does.
> But they don't get cleaned, so you won't notice unless you start with a fresh 
> clone
> And they aren't stored in the build dirctory, so nuking that doesn't get them.

I can't reproduce this.  I saw it a few times when you first reported it,
pushed a fix, and haven't seen it since.

> I'm not happy with the autorevision stuff.  Maybe just because I don't 
> understand it.
> 
> Have you tested it in tarball mode?  How is that supposed to work?  What gets 
> built before the tarball and what gets built after the tarball is unpacked?

Not only has it been tested, the new release script re-tests build from tarball
every time it's run. That's one of the "we fat fingered a point release" cases.
Mark didn't know that .wafhelpers/.autorevision-cache needed to be in the
tarball in order for autorevision.sh to work when it doesn't see a repository.

That's how it works.  When autorevision.sh sees a repository, it makes a
cache file of the info it gathers. When it doesn't, it looks for the cache.
If it can't find one, it barfs.  The cache file can't be checked in to
the repo or you get a dependency loop. 
 
More to follow addressing the second half of your note.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>