It is 19 days until our targeted September 28th release date for NTPsec 1.0.
My intention is that on Friday the 15th of September we will enter
feature freeze, with the remaining two weeks being devoted to testing,
bug fixes, and writing better tests.
Work on non-RFE tracker issues (currently #44, #55, #62, #269, and
#377) will be exempted from the freeze. We may also let things get a
bit slushier around the Python code if that comes up, as bugs there
don't threaten core function. But the C code has got to be left to
cool down - destabilizing changes just before a release are stupid and
embarassing.
This means the window on proposals to change the design of RFE
#204 (Support /etc/ntp.d) will close when we freeze. Plan whatever
time you can allocate to think up a better design accordingly.
One special circumstance might change the schedule. Daniel has a
family emergency that might prevent him from landing two security
features (info minimization and AES-CMAC packet validation) before the
freeze begins. I judge potential code disruption from both to be low
and their mission relevance to be high; it will be a judgment call, if
Daniel says he can land them after the 15th, whether we unfreeze or
negotiate a deadline extension with ICEI and reset the freeze
clock.
Everybody on the team has done spectacularly good work to get us to
this point. The rapid, effective response to the mystery crash
earlier this week is only the latest entry in a record to be very
proud of. Now we enter the home stretch.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
