Hal Murray <hmur...@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
