Forward-planning towards release 1.0

[Eric S. Raymond]

Heads up, Mark!  Possible strategy and external-relations issues.

I think we're no longer very far, technically, from being ready to
ship a 1.0 release.  This note is to outline what needs to be done,
suggest a rough timeframe, and lay out a couple of scenarios.

What brought 1.0 over the horizon was successfully landing Daniel's
protocol-machine refactoring.  There are a couple of rough spots
yet - peer mode is busted, MS-SNTP needs to be re-implemented, and
we need to make some decisions about broadcast and anycast modes -
but there's also no reason to expect that cleanup to take very long.

I polished off about a third of the GitLab tracker bugs today; there
are just 20 issues left on the tracker, all pretty routine-looking
stuff.  I think these can be done between and around major tasks.

Here's what I think we ought to do next:

* Fix symmetric-peer mode and MS-SNTP, definitely.

* Drop broadcast client mode, wich Daniel rightly notes is
  fundamentally impossible to secure

* Fix broadcast server mode, because Mark says a lot of Windows client
  users rely on it, but add a strong warning that it's a bad idea and
  users should transition out ASAP.

I don't understand "anycast" well enough to have a strong opinion.
Does anyone else? Is there any field evidence of use?

If we want to ship 1.0 fast, the right thing to do go into soft code
freeze after the cleanup, test for a some time, and ship.  We could, I
think, reasonably expect to ship late October or early November.
Let's call this "Case Red".

If we're in less of a hurry, the next logical point to freeze is after
landing the new restriction language.  If we split this up logically,
with me writing the config grammar and Daniel the internal primitive(s) for the
rules tables and evaluation, this isn't a big job either, nor one
paricularly difficult to test. I'd say another three weeks should
do it easily. Let's call this "Case Green".

If we're not in a hurry at all, then the *next* logical target is
moving ntpq all the way to Python. Not a really difficult job, but
a largish and somewhat messy one.  I'm going to say four weeks.
Let's call that "Case Blue".

Case Blue would leave us ready to ship 1.0 right around the end of the
year.

Which should we aim for? Have I missed anything serious? Discuss...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Everything you know is wrong.  But some of it is a useful first approximation.