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

[Nick Mathewson]

On Tue, Nov 23, 2010 at 12:06 AM, Andrew Lewman <andrew at torproject.org> wrote:
[...]

I should probably add this as a motivations section to the
SupportPolicy draft document.  Without an overview of how our lack of
clarity here has been hurting us, it's not obvious why we need more.

So here are some problems we've had, and how they have caused trouble.

First off, we have had little clarity about which releases are
"supported" with which kind of bug fixes at what time.  This creates
some problems, such as:
   * Users get told about end-of-life only after the fact.
   * People often decide whether to backport or not backport bugfixes
on a case-by-case basis with no real criteria to work from.
   * Because there are no criteria as to which bugfixes get
backported, and no clarity as to which releases we backport bugfixes
to, when we _have_ decided we should put out an update for a
not-latest release, we have sometimes found that we just can't do so,
because we would have to review the entire set of patches that went
into the more recent release, looking for ones to backport.
   * Questions of, "Must the network support routers of version X?
clients of version Y?" have been answered by "are there any left?"
rather than "is that still supported?"

Second, we haven't had much clarify about which operating systems we
support, with what effort.  From time to time, we break win98; from
time to time, somebody tells us and I spend a day or two figuring out
how to make it work again.  Vidalia's recent miniupnp stuff, I hear,
has problems on win2k.  Our explicitly stated policy wrt win98 has
been in the past, "If anybody notices we broke it, we might fix it".
I am pretty sure we broke win95 osr2 or whatever it was called without
meaning to at some point; it would have been nice to have done it on
purpose.

Knowing which operating systems and which versions of them we support
would help us get out of supporting ancient versions of our
dependencies.  We still have backward compatibility code for Libevent
1.0 and until recently we were maintaining backward compatibility code
for openssl 0.9.6.  Knowing what OSs we support can let us know what
we require.

So there are 4 questions we need to answer, from just a Tor
development POV, ignoring all bundling issues for now:
  * Which Tor versions do we support?
  * To what degree to we support them?
  * What operating systems do we try to run on, and how hard do we try?
  * Which library versions do we try to tolerate?

Here are some user goals:
  * Users should be able to answer the above questions clearly.
  * Users should always have a genuinely stable release to run that
works fine on the network.
  * Given that transitions between release series can be more
destabilizing than transitions within a release series, conservative
users should have a reasonably broad window in which to see if a new
stable series is stable enough for them before they upgrade.
   * Given that some operating systems that run a lot of relays
(notably the free linuxes) don't do major-release upgrades during
their series, we should

Here are some developer goals:
  * Developers should know what compatibility features are necessary,
and what compatibility features are a waste of time.
  * Developers who find a longstanding bug (say, "bugfix on
0.0.9pre8") should know which version to write their patch against.

Having written this up, I think I can come up with a simpler policy
that's still accurate and workable.  I'll revise and see if it makes
more sense.

yrs,
-- 
Nick