Forward-planning towards release 1.0

[Mark Atwood]

we need to be packaged for debian, rasbian, ubuntu, gentoo, redhat, and
suse for 1.0 and be working towards getting into their distribution system
(apt, yum, etc)

On Wed, Oct 5, 2016, 6:27 AM Eric S. Raymond <esr at thyrsus.com> wrote:

> 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.
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161005/26ce78df/attachment.html>