devchat notes from 10-Jan-2017

[Brian Warner]

(sorry this is so late, I forgot to send out the notes from last week)

Notes from the Tahoe-LAFS devchat 10-Jan-2017

* attendees: warner, meejah, liz, jp, str4d, daira, cypher, dawuud
* debian freeze is happening soon, trying to fix critical bugs and make
  a new release in the next week or so
* I2P bugs found at CCC
    * #2861: negotiation failure when i2p client connects to i2p server
      * str4d and warner to pair this time tomorrow
    * #2858: i2p provider/handler
      * PR33 on foolscap
    * #2859 can be closed
* tor blog post has a comment about #2862 (introducers.yaml docs syntax
  failure)
* extras_require on win32 (#2763) may require newer pip, check debian to
  see if it's in place
    * potential problem is that "pip install tahoe-lafs" on debian won't
      work
    * but debian packaging of tahoe-lafs would probably be ok
    * pip docs say platform= is supported since pip-6
* what version of twisted will go into the debian freeze (#2857)
* cloud-backend: warner should look at 2237.cloud-backend-merge.0
    * that is cloud-backend, with master merged in, with some additional
      meejah commits on top
    * still a few unit tests that fail
    * daira/meejah will do some rebase/rewriting work, merge master into
      it again
    * warner will treat that branch as a resource to mine diffs from,
      will review some diffs and apply to master
    * then new master will be merged into the branch again
    * over time the cloud-backend branch diff will shrink
    * big changes/refactoring
      * lots of APIs went from sync to async
      * so tests got harder
    * exarkun cautions against Mock and inlineCallbacks
      * see txaws tests: txaws.supplied.s3fake , returns pre-resolved
        Deferreds
      * use TestCase.successResultOf/failureResultOf instead of
        inlineCallbacks
      * mock leads you to tests that know too much about the internals
        of the implementation, and are fragile
      * instead, write second simple implementation of your real
        interface, which only operates on local memory
        * e.g. named "MemoryXYZ" instead of "XYZ"
      * write tests against that interface
      * tests can run against either implementation
      * one test runs against both, and uses external dependencies, etc,
        with async and inlineCallbacks
        * exercises XYZ specifically
      * other tests only use the simple implementation, and are
        synchronous
        * merely uses XYZ
* what people are interested in
    * meejah: servers of happiness
    * dawuud: generic accounting plugin api
* should tahoe be all "plumbing"?
    * command plugin mechanism like git/hg/twisted.plugins
    * should we add more stuff to tahoe itself, or to apps on top?
    * tahoe as library
    * application targets
      * things that need a key-value store
      * can we shape tahoe into a way that is suitable for those
        applications?
      * could we plug into slack? libre-office "save to my tahoe grid"
        option?
      * spideroak/semaphor storage backend?
      * Signal? Wire? file transfer backend
* when should the next summit be?
    * maybe before/after pycon in may? Portland
    * tor-dev in Montreal in september?
    * IFF in spain in march?
    * after CCC before RWC in jan-2018
* revocable immutable files? meejah
    * ask server to re-encrypt ciphertext with a stream cipher, append
      new key to an encrypted list, issue new readcaps

cheers,
 -Brian