Forward-planning towards release 1.0

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> I have no strong opinion about red vs green vs blue.

I don't either. I guess in general I lean towards waiting a little longer
and having a more impressive feature list.  But I laid out scenarios for
nearer-term releases because there might be PR or fundraising reasons
to do that.

> I think it would make more sense to have a high level description of what you 
> want for a release.  If you had that, I think it would be easy to pick a 
> color.

Hm.  I guess what I want is for it to be production-ready for large
datacenters - the AWS/Cisco/Rackspace league.  This is in concordance
with the deployment strategy Mark and I have talked about before.

> There are probably other areas that are just as important.
>   Are you planning to fix all the issues?

Yes. I cleared about a third of them yesterday. There are 20 left.
None of those look intractable.

Qualification: if the Pythonization of ntpq goes well enough and fast
enough, we may be able to ignore two of them that are about the C ntpq.

>   Has the pool vs restrict problem been fixed?

It has, and the fix has been verified.  That happened yesterday.

>   Is the documentation in good shape?

I think the major overhaul and update we gave it a year ago left it in
*very* good shape, as far as completeness and correctness goes.  I've
kept it current with our few new features since.

The worst problem I see remaining is that it's still something of a
jungle, somewhat difficult for a newbie to stay oriented in.  I
haven't figured out how to address that.  I don't think it needs more
content, but could maybe use a reorganization.

I think I may need to overhaul the HOWTO on writing a parse driver.
That's the one identifiable piece that may still be out of date.

>     What is the status of your simple setup doc?

Ready to ship. Your review and corrections were the last polishing step
I thought it needed.

>   What do we have in the way of testing?

That is the one area I'm not completely happy with.

Good news: We're doing really systematic cross-platform build testing now
and the breadth is only going to improve with the new buildbot jdb and gem
are working on.

Better news: Our defect rate has been really, really low. I've had
ntpd instances running on RasPis for literally months at a time, with
no crashes or unexplained anomalies *ever*.  We've had zero crash bugs
anywhere since we fixed that odd threads/rlimit interaction a while back;
that was our first and last.  The tracker bugs have all been pretty minor.

My only worry is that I wish we had more cross-platform testing in
production or quasi-production use going on.  I'm not as concerned
about this as I might be, because our defect rate has been so close to
zero, but I'd like to push the estimate out a couple more decimal
places.

>     (I think we were going to have a web page listing known good setups.)

We do; I made it from your devel/STATUS file.  It's not visible on the
public website yet because the website-rendering bot is down for a rewrite.

>   There are probably more "minor" cleanups in the code.  We keep finding them.

Agreed.  I think those will continue to happen naturally as we proceed.

>     I'd vote for getting rid of KERNEL_PLL.

I agree.  A good idea in itself, and I need to do it in order to figure out
whether your proposal for keeping TESTFRAME alive is viable.  Longer response
to that coming soon.

> How are you going to test MS-SNTP?
> 
> The old code, called out to a MS server to sign the response.  That tied up 
> the server.  The people who needed it were running low volume so they were OK 
> with that.

That's an issue I was not aware of, and makes me want to drop the feature.
How important do you think it is?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>