wiki:MeetingNotes_2012_10_23

Version 7 (modified by davidsarah, at 2012-10-24T00:36:31Z) (diff)

add xkcd ref :-)

Dev Meeting Archive: 2012-10-23

Note: This came from an OpenEtherPad transcription, but hopefully has been updated to supply missing details or correct mistakes.

Source: http://openetherpad.org/SbIhGULiyq

Zooko mentions problems from upgrading his kernel: http://xkcd.com/349/

  • 15:43 - Reviewing ticket #1240

Post-Meeting Update: The discrepancy in test failure is between two consecutive commits on amiller's branch; after the meeting, IRC conversation revealed why this commit fixed the test, which was unclear at the meeting onset.

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

A repository with the patch: https://github.com/amiller/tahoe-lafs/tree/amiller-1240

Getting to amiller's state:

$ mkdir tahoe-lafs-amiller ; cd ./tahoe-lafs-amiller
$ git clone https://github.com/amiller/tahoe-lafs.git
$ cd tahoe-lafs
$ git checkout amiller-1240

amiller: There's a period of time where the tests did not fail, but then they did fail. It was hard to follow through the code. amiller considers a heisenbug or it could be because it's hard to grok twisted errors.

davidsarah & amiller are running the tests independently to see the results.

NOTE: The hangout chat feature is horrible (most users won't see it, and if they enable it later they don't have history), so there's a dump at the bottom of the openetherpad page. Future chat should always be into IRC.

  • 15:54 - Many people are running tests on their local machines

amiller shares his terminal, and zooms on test_mutable.py, test_retrieve_surprise.

zooko suggests this test relies on the ResponseCache which the patch has removed; but it's not clear that the test needs to rely on this cache.

  • 16:10 - More discussion of the specific test

david-sarah changes "self.old_map.best_recoverable_version()" to "n.get_best_readable_version()" to see a different error and asks if that's the expected error for this test.

zooko suggests the current test has four steps:

  • overwrite file
  • ?
  • ?
  • download again with the stale map

zooko: to make the test work, we need a stale map but we need the cache to be cleared (or not relied upon). Question: Where is it getting the data from the cache.

amiller: Not quite sure but probably when creating the mutable file. Maybe alter the test to detect when the cache is populated. A change in amiller's patch is that the cache key has a version in it.

Zooko suggests extracting the readcap, then using that readcap for the rest of the test which will not have the cached state.

  • 16:15 - Zooko describes Tahoe birthday party:

In Boulder at ~23:00 utc on Saturday. It might just be Zooko.

Others should plan to connect with hangouts and projectors.

-From IRC- warner mentions that it was inconvenient to translate from UTC to local time in his head; nejucomo offers to put common local timezones on the wiki page.

  • 16:20 - Returning to discussion about the failing test in amiller's branch.

zooko suggests a follow-on to ticket 1240 is to review the cache involved in this patch to ensure that it is actually getting hit and justified.

davidsarah modified the test to explicitly clear the node cache (http://codepad.org/LIj7CF0t), which is what zooko suggested, but the test still does not work and generates the same error. The old contents are still present which was not expected, so maybe there is yet another cache.

amiller suggests adding prints for object identities to debug the caching behavior further. (This is included in http://codepad.org/LIj7CF0t)

  • 16:25 - Zooko discusses topics for next meeting.

He says the debug session in this meeting was very useful. He's interested in both "nuts and bolts" and science/design stuff, aka "tesla coils and ..."

Zooko: Proof of Retrievability paper is nearly ready for reviewing at a meeting.

Zooko: Rainhill design by David-Sarah needs review by crypto experts.

David-Sarah: It might be possible to simplify Rainhill in some way.

Zooko: Possible approaches for rainhill:

  • document its security features
  • explain why the complexity is necessary for features
  • determine if simpler constructs achieve those features

Zooko: Wants to advertise rainhill for broader crypto community review. Suggests next week will be PoR topic, then the week after could be Rainhill; after some advertising.

Everyone agrees.