[tor-relays] Re: support policy vs. actual expectations beyond the end-of-life date

[Scott Bennett via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx>]

nusenu via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:

> TLDR: There appears to be a mismatch between the support policy [1] vs. actual expectations from torproject people,
> it would be beneficial to clarify and update the policy and documentation to avoid similar situations
> (different expectations and understandings of what EOL means in the context of the torproject)
> in the future and so we and others can learn from it and hopefully prevent it from happening again.
>
> Shortly after the release and feedback in this thread I added a note to the release information about delaying the upgrade to relayor v26.2.0
> if the operator runs relays across more than one /16 IPv4 or /32 IPv6 network.
>
> ahf wrote:
> > When a release goes EOL, we have a period where we can work with
> > other people and partners, who are in contact with us, about their
> > use of Tor. During this time, we can hint to them at upgrading. Some
> > of the reasons for upgrading are new features, safety, and security
> > issues. We are not in a hurry at all here.
>
> It is clear now - after the emails in this thread - that some have expectations that go
> beyond the end-of-life date of a tor release series.
>
> 1) The current support policy does not document the mentioned stages after the EOL date.
> The current support policy [1] from Jul 19, 2022 describes these stages:
>
>         -> alpha
>          -> release candiate (rc)
>           -> stable
>            -> oldstable
>             -> end-of-life
>
> So according to that policy the last event in the lifecycle of a tor release series is the end-of-life date.
> End-of-life releases are unsupported and "You are on your own.":
>
> [1]:
> > After that, the release will be considered End of Life (EOL) as in
> > unsupported meaning that at any point after that state is set for the release
> > series, the directory authorities might reject them from the consensus.
>
> Most notably [1] and [2] do not say anything about the mentioned additional stages beyond the end-of-life date,
> in the specific case of 0.4.8 the stage between 2026-06-01 - 2026-09-01 and the stage after 2026-09-01.
>
> 2) Clarifying [1] with the mentioned expectations would be beneficial
>
> I also created a gitlab issue for this under:
> https://gitlab.torproject.org/tpo/core/team/-/work_items/32
>
> a) EOL meaning
>
> Since the term "end-of-life" already has a certain meaning in the software world https://en.wikipedia.org/wiki/Software_release_life_cycle#End-of-life
> I think it is best do not create a torproject specific meaning of "end-of-life" to avoid similar confusion in the future.

     While I support this argument, I wish to point out the hypocrisy of anyone
so involved in the Tor Project, which itself violated this policy early on and
has continued to do so for over 20 years, now making the argument at this late
date.
     When I first became aware of tor and began to use it, I was confused for
some time by its misuse of the term "alpha" releases.  From the mid 1960s
through the early 1990s, during which time the vast majority of software
publicly available was written by hardware vendors, e.g., Burroughs, CDC, DEC,
Fujitsu/Facom, Harris, Honeywell, IBM, ICL, NCR.  In the customer (a.k.a.
"user") communities, beta releases were known, but very few customer sites
chose to sign the vendors' contracts for the privilege of being on the
bleeding edge of development by being a beta test site.  Those that did so,
however, were reputed to receive intensive support in analyzing bugs and
producing fixes for them.  Alpha releases, by contrast, were basically out of
view outside the vendor corporations themselves and were basically under tight
wraps.  It was occasionally possible to get some company representative to
admit that alpha releases did exist, but they wouldn't admit to having any
information about them except that they were strictly internal to those
corpations.  Thus, after having always heard the terms used with these
understandings, it took me a while to understand that the Tor Project was yet
another victim of NIH Syndrome in its own small way. :-)
     Another example in a much larger way was the CSRG at U.C. Berkeley, who
apparently ignored much of the terminology previously invented elsewhere in the
development of support for virtual memory systems and instead invented their
own.  All of the modern BSDs continue to use that vocabulary.  One serious,
deficiency, IMO, of the CSRG's terminology was the lack of the term "page
frame" and the consequent substitution of the word "page", which results in
their use of "page" for two different, but very related, concepts.  That can
lead to a great deal of confusion in some situations.
     Anyway, yes, please do publish clear definitions for the different phases
of the tor project's software support cycle (a.k.a. "life" cycle).


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************
_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx