[tahoe-lafs-trac-stream] [tahoe-lafs] #1452: clarify policy about what versions of dependencies Tahoe-LAFS requires

[tahoe-lafs]

#1452: clarify policy about what versions of dependencies Tahoe-LAFS requires
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  somebody
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  soon (release n/a)
    Component:           |    Version:  1.8.2
  packaging              |   Keywords:  packaging setuptools exocet testing
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Old description:

> There are conflicting ideas about how tight to make the requirements
> Tahoe-LAFS should place on dependencies (in
> [source:src/allmydata/_auto_deps.py]). One way to do it would to be
> require versions of dependencies which we know work with Tahoe-LAFS (i.e.
> they don't have any critical bugs that are triggered by the way Tahoe-
> LAFS uses them nor fatal incompatibilities with Tahoe-LAFS or other code
> that Tahoe-LAFS uses). This would be the tightest policy. The other
> extreme—the loosest policy—is to allow any version unless we know for
> sure that particular version has a critical bug or incompatibility.
>
> I personally find it a bit dubious if we specify that Tahoe-LAFS requires
> a version of {{{Package X}}} greater than or equal to {{{Version N}}}, if
> we don't have any buildbots that have {{{Version N}}} installed. To me
> that sounds like we are claiming that Tahoe-LAFS will work with
> {{{Version N}}} of {{{Package X}}}, but making that claim without
> reproducible evidence that it is true. On the other hand we can just rely
> on the absence of any bug reports from the field which can be traced to a
> bug or incompatibility in some version of one of our dependencies.
>
> One possible future improvement would be to automate the testing of
> Tahoe-LAFS combined with different versions of dependencies. The exocet
> tool looks like it might facilitate that sort of work:
> [http://washort.twistedmatrix.com/2011/03/exocet-second-look.html Exocet:
> A Second Look]
>
> In the meantime, let's write down a policy on our Wiki and close this
> ticket.
>
> Another option would be to choose a set of operating
> systems/distributions that we think we should support and specify the
> versions of the dependencies which are provided in those. Currently we
> have the following operating systems/distributions in the Supported
> Builders category of our buildbot herd: Windows 7 x86_64, Debian 5
> "Lenny" ("obsolete stable") x86_64, Ubuntu 10.04 "Lucid" x86_64, Ubuntu
> 10.10 "Maverick" x86_64, Debian 5 "Lenny" ("obsolete stable") x86,
> FreeBSD 8.2 x86_64, OpenBSD 4.8 x86_64, NetBSD 5 x86, CentOS 5 (!RedHat
> 5.6) x86, Windows XP 5.1 SP 3 x86.

New description:

 There are conflicting ideas about how tight to make the requirements
 Tahoe-LAFS should place on dependencies (in
 [source:src/allmydata/_auto_deps.py]). One way to do it would to be
 require versions of dependencies which we know work with Tahoe-LAFS (i.e.
 they don't have any critical bugs that are triggered by the way Tahoe-LAFS
 uses them nor fatal incompatibilities with Tahoe-LAFS or other code that
 Tahoe-LAFS uses). This would be the tightest policy. The other extreme—the
 loosest policy—is to allow any version unless we know for sure that
 particular version has a critical bug or incompatibility.

 I personally find it a bit dubious if we specify that Tahoe-LAFS requires
 a version of {{{Package X}}} greater than or equal to {{{Version N}}}, if
 we don't have any buildbots that have {{{Version N}}} installed. To me
 that sounds like we are claiming that Tahoe-LAFS will work with {{{Version
 N}}} of {{{Package X}}}, but making that claim without reproducible
 evidence that it is true. On the other hand we can just rely on the
 absence of any bug reports from the field which can be traced to a bug or
 incompatibility in some version of one of our dependencies.

 One possible future improvement would be to automate the testing of Tahoe-
 LAFS combined with different versions of dependencies. The exocet tool
 looks like it might facilitate that sort of work:
 [http://washort.twistedmatrix.com/2011/03/exocet-second-look.html Exocet:
 A Second Look]

 In the meantime, let's write down a policy on our Wiki and close this
 ticket.

 Another option would be to choose a set of operating systems/distributions
 that we think we should support and specify the versions of the
 dependencies which are provided in those. Currently we have the following
 operating systems/distributions in the Supported Builders category of our
 buildbot herd: Windows 7 x86_64, Debian 5 "Lenny" ("obsolete stable")
 x86_64, Ubuntu 10.04 "Lucid" x86_64, Ubuntu 10.10 "Maverick" x86_64,
 Debian 5 "Lenny" ("obsolete stable") x86, FreeBSD 8.2 x86_64, OpenBSD 4.8
 x86_64, NetBSD 5 x86, CentOS 5 (!RedHat 5.6) x86, Windows XP 5.1 SP 3 x86.

--

Comment (by zooko):

 Okay, I believe that what we're going to do is this:

 We don't change the dependency version requirements (in
 [source:trunk/src/allmydata/_auto_deps.py?annotate=blame&rev=7bb07fb5e28756fa13ba5190e6c39003c84d3e1e
 _auto_deps.py]) unless something forces us to change them. That's because
 we're lazy, and not making changes is easier and less disruptive than
 making changes.

 However, this means that what is written in _auto_deps.py is not an
 assertion on our part that these versions of the deps will function and be
 secure. Instead, it is just a record of the fact that nobody has shown us
 a problem with them that forced us to update them. In particular, we
 aren't making any particular effort to test with the older versions that
 we list as the minimum required versions.

 So, to close this ticket, write this policy down somewhere, possibly just
 in a comment in _auto_deps.py, and then link to the patch that documents
 our policy and close this ticket.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1452#comment:5>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage