Draft schedule for Tor 0.2.1.x.

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

Hi, folks!

It's time to start talking more about what goes into the next release
of Tor, the 0.2.1.x series.  I think this release's development will
go much more smoothly if we have rough time windows in mind for when
parts of its development need to be done.

These are all rough targets.  We can bend them if we have a big reason
to do so, such as fixing a big security problem or interoperating
right with an important external project.  On the other hand, we
shouldn't bend them unless we're willing to risk delaying the release
by doing so.  I've tried to include rationales inline.

Here are the rough dates for the next release:

==============================
June 30: PROPOSAL CUTOFF.

All feature proposals for consideration should be in and discussed
before this date.  In the meantime, we should already be implementing
accepted proposals.  Note also the "and discussed": complex proposals
received on June 29 are unlikely to be adequately discussed by June
30.

Trivial proposals might be accepted after this date, if they are
indeed trivial.

July 15: ARCHITECTURE FREEZE.

No major architectural changes should get made to Tor after this date.
[I'm leaving "major architectural change" deliberately underdefined.
It would definitely include switching how we use libevent buffers, or
making big changes to our threading model.]

August 15: FEATURE FREEZE.

No new features should be added after this date.  This is when we
should move to pure testing and bugfixing.

September 15: FIRST RELEASE CANDIDATE

If we've not pushed the other deadlines too hard, we should be ready
for release by now.
==============================

Note that the important thing to do now is to improve and discuss
feature proposals, and write new ones.

yrs,
-- 
Nick Mathewson