Nuts & Bolts report

[Zooko O'Whielacronx]

.. -*- coding: utf-8-with-signature-unix; fill-column: 73; -*-

Tahoe-LAFS Nuts & Bolts, 2015-02-10Z
====================================

in attendance: Daira, Brian, Zooko (scribe), David

We worked on the upcoming Tahoe-LAFS v1.10.1 release. We reviewed,
refactored, and merged a new contribution from Chris chatcannon Kerr
to allow combining automatically-detected IP addresses with
manually-specified IP addresses:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/754

https://tahoe-lafs.org/trac/tahoe-lafs/changeset/2d9af506f1d315016d0d63d6a7491ecd2a370448/trunk

That feature hadn't previously been intended to go into Tahoe-LAFS
v1.10.1, but since it is a complete patch with unit tests, a useful
feature, and has a low chance of introducing new bugs, we've decided
to include it in v1.10.1.

We debated — *again* — the precise semantics of `tahoe cp -r`. Here is
a chart of the old (Tahoe-LAFS v1.10.0), current (HEAD of trunk), and
next (Tahoe-LAFS v1.10.1) behavior for different kinds of arguments:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2329#comment:25

Here's a proposed algorithm that would implement the Tahoe-LAFS
v1.10.1 behavior:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2329#comment:27

Brian will try to implement it, and will expand the table to show the
different behavior between `tahoe cp -r` vs. `tahoe cp`.

David opened a new ticket for removing an identity/linkage leak from
client Tub IDs:

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2384

We observed that switching from Foolscap to a custom LAFS protocol on
top of HTTP would eliminate that linkage.