My pre-1.0 wishlist

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> Nice.  Thanks.
> 
> I'm assuming that the major decision on what we call 1.0 will be political, 
> aka Mark's call.

That is my assumption as well.

> An item I would put on the list would be a written recipe/checklist for how 
> to do a release.  I think when we get into "real" releases, that recipe will 
> need several branches:
>   one for minor releases
>   one for major releases
>   one for bug fixes and security patches.

You've been agitating for this for a long time.  And reasonably so, but I
don't see anyone stepping up to write it. Can you do it?

> It would be nice to have a list of configurations that are known to work, 
> including refclocks.

Agreed, it would. But if we've verified function with anything outside
{20,22,28,46} I sure don't know about it.

> > 1. End-to-end test automation
> 
> I think there are 2 branches to this.  One is automation in the sense of 
> TESTFRAME.  The other is automation in the sense of it's running and we 
> automate watching it.

Agreed.

> > 6. An NTP Classic -> NTPsec migration guide
> 
> That will mostly be a list of features we have removed.  If you don't use 
> those features, migration is as simple as changing the file name of the 
> program you run in the start/stop scripts and/or installing the one you want 
> to run on top of the old one.

One reason it was easy for me to agree to put this on a presumptive blocker list
is that I've already written most of it.  See at https://docs.ntpsec.org/latest/
"Differences from NTP Classic".

There really isn't much more to be said than that; probably the
biggest deal I didn't write down is that because of the command-line
parsing no longer being done by autogen, the names of some help options
have changed from -? to -h.

The reason all this is so easy to document is that where I haven't
outright removed stuff, I've been as conservative as is possible about
changing user-visible features.  To be honest, this is in part because
my outside view of the code was extremely poor until recently - even
had I been of a mind to "improve" things, I wouldn't have been sure
what was safe to touch.  To a significant degree I'm still not.

> It's probably a bit more complicated than that.  I'm not sure that ntpdig is 
> a full replacement for ntpdate.

>From the header comment of ntpdate:

# Not documented, as this is strictly a backward-compatibility shim. It's
# based on the recipes at
#           http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
# with corrections for modern ntpdig options.
#
# Known bugs:
# * The -e and -p options of ntpdate are not yet implemented.
# * ntpdate took 4 samples and chose the best (shortest trip time).
#   This takes the first.

> > We've been talking for a long time about replacing the 'restrict' directive
> > and all the language around what keys have what authorizations with
> > something sane. We should get this done before 1.0. 
> 
> I could vote for deferring that as long as possible to maintain compatibility 
> at the ntp.conf level.  But if it's a serious cleanup, then we should do it 
> whenever it's convenient for us and our users.

I agree with both of you, in a sense.

In principle, I think Hal is right - we should do it whenever it's
convenient for us and our users.

In practice, there will never be an inconvenient time for this from my
POV; I could hack Yacc/Lex grammars at the required level while blind
drunk, if I drank.  That's why it was easy for me to agree with
Daniel's wish.

Really, unless Daniel does something unexpectedly weird with
the spec, or the structures the grammar is manipulating are seriously
bent, analysis and code and docs should be a couple of hours of relaxing
vacation play.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>