Mark Atwood, checking in, and requesting checkin

Mark Atwood fallenpegasus at
Mon Feb 29 20:28:11 UTC 2016

Good work!

On Mon, Feb 29, 2016, 11:57 AM Eric S. Raymond <esr at> wrote:

> Mark Atwood <fallenpegasus at>:
> > My apologies for dropping the ball last week, this week I will tag and
> > release 0.9.3, probably on Wednesday.
> The delay was not a bad thing.  We had a couple good documentation fixes
> and a build cleanup land- nothing major, but nice.
> > I am now managing the open source engagement for the OpenSwitch project,
> > and I plan on arranging to have ntpsec be the implementation that
> > OpenSwitch uses.
> Nice!
> > I notice that Coverty scan has found two warnings.  Can someone open bugs
> > for them, and then fix them?
> Already been done - Matt Selsky developed a fix and I merged it.  I'd
> have done a fix myself sooner, but the code that was generating the
> warnings is going to go away when replay lands.  It was
> instrumentation of mine, not timekeeping logic.
> > Eric:
> > - what is the status of testframe
> > - what else have you been working on this week?
> Testframe is proceeding, slowly.  Every time I think I'm converging on a
> final version (so far) I trip over some internal cohesion I have to
> separate;
> it's tricky work to do that without breaking existing functionality.
> It has been a busier week than the last several for dealing with
> (other) merge requests and issues.  Nothing serious, just a lot of
> details to track and manage.
> Last weekend I co-wrote and released a HOWTO for people who need to
> forward-port Python 2 programs that handle binary data to Python 3.
> Because of the big string-to-Unicode change this is a bit tricky.
> Practical Python porting for systems programmers:
> NTPsec utilities are exactly the use case the HOWTO addresses,
> actually, and that's no coincidence. While I tested the methodology on
> SRC and reposurgeon, in the near future we're going to want to move the
> archaic Perl in our scripts directories to something maintainable, and
> polymorphic Python (that is, Python code that auto-adapts to 2 or 3)
> is the best candidate.
> Now I not only know how to write polymorphic Python that is 8-bit-clean for
> binary streams, I've written the technique down so we can delegate the
> utility
> translation.
> --
>                 <a href="">Eric S. Raymond</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list