Time to plan for 1.0
Eric S. Raymond
esr at thyrsus.com
Mon Aug 7 21:03:24 UTC 2017
Daniel Franke <dfoxfranke at gmail.com>:
> If we're aiming for a September 28 release then I propose we should
> have a dev freeze by September 1. Bug fixes only during that month;
> anything that's mere polishing goes on a branch.
> I don't want to release 1.0 without having
> implemented. As of the last IETF meeting I'm confident that there
> aren't going to be any significant normative changes before it's
> finalized. I'll make the time for this before my proposed September 1
I'm not sure that declaring a dev freeze would be meaningful. The only
activity that would be affected (that, is, the only stuff not directly
addressing a pending tracker issue) would be Ian's work on the snmpd
server. I'm willing to consider that a special case, since it's completely
isolated from the C core and we might not ship it in 1.0 anyway.
About all a dev freeze would mean is that we start deferring feature MRs that
touch the C.
I'd also like to avoid holding the release to an artificially late date.
You want data minimization in; Mark wants Debian packaging. That's fine but
I think we should plan in terms of shipping very soon after those land, like
with a three-day cool-down.
When is the soonest you think you can work in data minimization?
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
More information about the devel