[tor-packagers] [tor-dev] Proposed changes to Tor long-term-support (LTS) policy

[Markus Reichelt]

Hi Nick,

I'm the current maintainer for Tor at SlackBuilds.org; scripts are
provided to users so that they can build their own packages on stock
systems. Scripts are approved before publication.


* Nick Mathewson <nickm at torproject.org> wrote:

> Many packagers don't like it, because they have a policy of
> auditing security backports, and we backport too much to our LTS
> releases for them to audit carefully.

Auditing such backports is beyond my capabilities.  I merely test for
functionality in the realm of my personal usage pattern on the last
stable Slackware release as well as on -current.

Presently this encompasses running a few private bridges, a relay,
and hidden services as needed, and using Tor-browser on Windows &
Slackware test-driving a few selected websites.


Here's my approach to testing:

* private bridges test both last stable (like 0.4.4.7) & -alpha/-rc
* the relay only tests last stable
* with hidden services it's either last stable or -alpha/-rc, there is
  no def. commitment; mostly a PoC-thingy for non-critical stuff

my approach to 'packaging' is simple, and my motivation behind it kind
of resonates partially with your main goal here I think:

* package the last stable release so that folks can test-drive the
  latest features/security fixes within their scope of use, if they
  want but also keep former stable releases available through the SBo
  git repository, for users who know their way with git.


> We propose the following release statuses:

fine by me.

-- 
feel the magic of Tahoe-LAFS