Thoughts on https://trac.torproject.org/projects/tor/wiki/dev/SupportPolicy

[Andrew Lewman]

My initial impressions are effectively summarized as "wow, this is long
and complex!  Does it really need to be so?"

One thought is how thandy/secure updater affects this plan. I see we'll
still need to handle alpha vs. stable in some way, but the rest seems to
be easier to maintain.

From a past packing perspective, having anything more than 2 branches
to maintain and build was suboptimal.  If package building is automated,
it may still be suboptimal, but less of a nuisance because packages
magically appears hours after one starts the build farm building
packages.

I've always viewed -alpha and -stable as feature dependent.  -alpha
gets new features, -stable is frozen in time with respect to features
and only gets bugfixes.  In both branches, bugfixes are prominent
throughout their lifetimes.  Therefore, I propose a simple set of 2
branches, -alpha and -stable. -alpha continues to get new features and
bugfixes as we create them.  -stable continues to only receive
bugfixes on its existing features.  

When we're happy with the set of features in -alpha, or something
else is driving the creation of new and crazy features, we do a
feature freeze.  Only bugfixes to existing features are included
during this phase.  When an -alpha switches to -stable, the former
-stable is now obsolete and at end of life. The desire for a new -alpha
may force the switch to -stable.   I think having more than 2 branches
creates much more work for us.

The previous two paragraphs are perhaps a loose interpretation of what
we have done in the recent past.

As for operating system support, I'm fine with supporting whatever the
current OS manufacturer (for loose meanings of organization that
creates the releases) supports.  I'd caution this with finding out what
our users actually need.  There are a many places in the world where
they use operating systems from more than 10 years ago.  If we truly
want to help people, both -alpha and -stable branches should have wide
and a variety of OS functionality.

As of last winter when I did some testing, Tor (the binary itself) runs
under Win98 through Windows 7, OS X 10.3 through 10.6, and Fedora 10
through current.  

As for packages, I suggest we support the current release of an OS plus
two previous versions.  We could rely upon the OS versions of
libraries rather than bundle our own.  In an optimal world, we ship our
own libraries for Tor rather than relying upon various vendors to keep
up to date.  This lets us control features and some part of an operating
environment for tor.  I'm primarily thinking of zlib, openssl, and
libevent 1 or 2 for inclusion here.  My idea of an optimal world may
need thandy implemented to make it a reality.  

I think trying to keep lists of OSes and their various libraries is
going to create work for little gain.  If the OS does not have our
minimum requirements, such as openssl 0.9.8, libevent 1.4, etc ,then we
cannot run on that OS.  Users can build their own tor from source, if
so desired.

My goals here are to keep things simple.  I worry that a complex set of
rules for releases will bog us down and not force us to make decisions
to keep tor progressing along as it has for the past few years.

-- 
Andrew
pgp 0x31B0974B