On Tue, Nov 23, 2010 at 12:06 AM, Andrew Lewman <[email protected]> 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
