[tahoe-dev] Tahoe-LAFS Weekly Dev Call 2012-09-04

[Zooko Wilcox-O'Hearn]

In attendance: Brian, David-Sarah, Andrew Miller, Zooko

scribe: Zooko (standard caveat applies: this hasty summary may be
inaccurate or lacking in context)

comms tech: Google Hangouts

agenda: ticket triage for Tahoe-LAFS v1.10

We went through the highest priority tickets for Tahoe-LAFS v1.10. The
one that was already reviewed and was just awaiting merge (#1240), the
ones that were already marked as "review-needed", the ones that were
marked as of critical priority, and quite a few others.

For each one, we decided whether to eject it from the Tahoe-LAFS v1.10
Milestone or leave it in and try to finish it right away. The general
criteria were that if it was already done, or so close to already done
that we could most likely get it finished in a few days, then it
stayed in.

You can see the results by browsing the "Milestone 1.10" part of the Roadmap:

https://tahoe-lafs.org/trac/tahoe-lafs/milestone/1.10.0

And of course by browsing the Timeline:

https://tahoe-lafs.org/trac/tahoe-lafs/timeline

There was some discussion about the development process. It's a shame
that every time we get to this stage of the of the release cycle,
there are some tickets that somebody is motivated to fix, but it is
too late to get them fixed in *this* release, so they get put off til
next release. The problem is, they often don't get looked at again
until it is too late for *that* release. We need to have a moment when
you are motivated to fix stuff, because it is almost time to put it
into the imminent new release, but it is not already too late to do
so. So, we're thinking of organizing a "It's Not Too Late!" party
about one week *before* the "Final Bug Triage", next time around (the
code that will become Tahoe-LAFS v1.11).

There were two other topics about the development process: one is that
we should train people up in how to contribute unit tests, and the
other is that we should try to get Kevan back into the game.

Unit test writing: there are several patches that have been
contributed which are not already merged into the codebase *only*
because they don't have unit tests. The contributors are, they have
said, willing to spend some time writing unit tests in order to get
their patches accepted, but they don't know where to start. Our test
code is huge, not all that well structured, and not documented. (Aside
from this doc that I started last time we were in this part of the
release cycle:  ¹).

The specific patches we triaged today that are missing tests are this
new one by kick: #1735, and this old one by Leif: #648

So, in my opinion we should have a "Unit Test Writing Party" in which
we use IRC and/or Google Hangouts to show contributors how to write
unit tests for the patches they care about.

The other topic was whether Kevan is going to dive back into
contributing to Tahoe-LAFS. We looked at this patch that Kevan wrote
-- #1641. It looks like a valuable change -- fixing a regression or
two in which Tahoe-LAFS v1.9 may have started failing or misbehaving
in some rare cases in a way that Tahoe-LAFS v1.8 didn't. And, it comes
with thorough tests (Kevan is good about that). But we didn't put it
in. Why not? Because Kevan wasn't on the Weekly Conference Call this
week to talk about it, and because his comments on the ticket sound a
little bit unsure, and because nobody else understands that code well
enough to judge it on the spot.

I expressed the hope that he'll start joining us again now that he's
finished with school and settled into his new job.

This led the discussion to into decentralized secure mutability in
general, and if other approaches would be easier to implement than the
Tahoe-LAFS mutable files. Brian said if he were starting over on a
LAFS-like design he would try to limit mutability to a single small
replaceable slot (like they do in some programming languages which try
to constrain mutability), so that the only thing you could ever mutate
would be the contents of a slot which can hold only one capability.
Andrew said that mutable files is one solution to the widely-studied
problem of decentralized consensus, and that viewing it from a
sufficiently abstract perspective might show new alternatives, such as
using the Bitcoin blockchain (which is a mechanism for providing
distributed consensus) to resolve conflicts. Someone, I forget who --
maybe elb on IRC -- opined that it might make sense for Tahoe-LAFS to
concentrate on immutable files and make the handling of mutation and
update Someone Else's Problem. I retorted that there's nothing
stopping people from putting LAFS immutable file caps into their apps
now.

I argued that the Tahoe-LAFS mutable files are actually an excellent
design, a step ahead of any other distributed, secure, mutable data
system that I'm aware of , and that we should push harder on fixing
the bugs in the implementation and improving the efficiency and
expressiveness of this design. (By improving the expressiveness, I
mean things like implementing  add-only-sets #795, write-only-caps
#796, revocation-of-write-authority #954, and so on.) Andrew Miller
concurred, saying that LAFS mutable files are the best implementation
that he knows of one of the best approaches to the general problem.

We agreed that ticket #68 should be taken to the tahoe-dev list to
hash out some consensus on whether we want to support
multiple-introducers or skip straight to gossip (which is kind of like
"everyone is an introducer all the time").

Your humble scribe,

Zooko

¹  https://tahoe-lafs.org/trac/tahoe-lafs/wiki/HowToWriteTests

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement
distributed introduction, remove Introducer as a single point of
failure
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/648# collect server
capacities and put them on the welcome page
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795# append-only files
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/796# write-only backup caps
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/954# revocable write authority
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1240# remove
ResponseCache in favour of MDMFSlotReadProxy's cache
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1641# fix regressions in
convergent uncoordinated write detection
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1735# the banner on the
Welcome page saying that a helper is not configured should not be red