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 _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
