Folks: "I would not have made this so long except that I do not have the leisure to make it shorter."
It's late here. I don't have time to write well-organized letters, but I think it might be better for everyone to see an ill-organized letter on this topic that to carry on without a letter, so here it is. = Tahoe-LAFS v1.8 planning = The current plan is make a 1.8β release six days from now, on Monday 2010-08-02. See The Roadmap [1]. Generally speaking, if a patch isn't finished and ready for review by Saturday night (UTC-6) 2010-07-31 then I'll be inclined to put that patch into the "post 1.8" bucket. I hope to do all of the "release chores" on Sunday so there's nothing left to do but push the big red button on Monday. The release chores include updating the wiki, writing the release announcement, writing cover letters for the release announcement, etc. etc. [2]. Help is welcome! I'm getting kind of tired of that job, but I don't want to turn the job over to someone else because they might not do it exactly the way that I like. So what's going to go into 1.8? == Brian's New Downloader (ticket #798) == A long-awaited rewrite of the downloader which will improve robustness and probably also improve performance in many situations. Needs code review with an eye to avoiding regressions vs. 1.7.1 including performance regressions. Needs benchmarking to compare it to v1.7.1. == "get rid of tahoe.exe launcher" (ticket #1074) == Let the tahoe cli run on Win64, make it possible to do non-ASCII command-line arguments and outputs on Windows, remove a binary blob from our build system and otherwise simplify the build system and improve the tests thereof. == update pycryptopp (pycryptopp tickets #18, #34, #37, #43, #44, #45) == See also this mailing list message [3]. == other bugfixes and usability improvements == See The Roadmap. And please help! Help needed. There are many tickets on The Roadmap that desperately wish they could be fixed in v1.8 and they need a loving hacker to help them get there. In addition to the above, I'm hoping that each of the Google Summer of Code students will try to land some patches for v1.8. That's because it would be awesome if they got code committed for v1.8, and anyway the best way to get patches committed into v1.9 is to try to get your patches committed into v1.8 and fail. ;-) == Kevan Carstensen's MDMF (ticket #393) == Kevan has done a ton of deep work on this (see the ticket history and attached patches), but I don't know if any of it is ready to be reviewed for committing to trunk. Kevan and his Mentor, Brian, should probably think about whether there is anything likely to be ready by Saturday and also whether there are any forward-compatibility issues such that we should commit some changes to v1.8 just so that v1.8 will interoperate better with the eventual v1.9 that has the complete set of #393 patches. == Faruq Sarker's Decentralized Introduction (ticket #68) == Faruq and his Mentor (me) should see if he can get the first part of #68 committed this week. See also mailing list message [4]. == Yu Xue's 100 Year Cryptography == Per this mailing list discussion [5], I want Yu Xue to work on getting a combined cipher into Tahoe-LAFS as soon as possible, and he is willing to do that. I haven't heard from his Mentor, Jack Lloyd about it yet. The next steps are: 1. Define some way to indicate in the cap itself that it is an "XSalsa20⊕AES-128" cap which is just like the Tahoe-LAFS v1.7.1 cap except that it is encrypted with XSalsa20⊕AES-128 instead of with AES-256. 2. Implement a combined XSalsa20⊕AES-128 mode in a patch for pycryptopp. 3. Write unit tests for it like the analogous unit tests for AES which are currently in pycryptopp: http://tahoe-lafs.org/trac/pycryptopp/browser/trunk/pycryptopp/test/test_aes.py?rev=20100601041454-92b7f-aea971430644c5779d0abd128ee2ae85d1823919 4. Write "quick start-up self-tests" for XSalsa20⊕AES-128 analogous to these "quick start-up self-tests" for AES-256: http://tahoe-lafs.org/trac/pycryptopp/changeset/20091030222709-92b7f-49fea5a4bab83f10bd10fc2236ead238615ddcf8/trunk == Josip Lisec's Tahoe-LAFS-hosted Music Player App == I don't know. Josip: is there anything that would need to be added or not-added to Tahoe-LAFS v1.8 to facilitate your music player app? How is it going, anyway? = Administrivia = The servers that run the web site, trac, darcs repositories, mailing lists, etc. are sometimes unavailable. Suspicion currently falls on Peter's router at The Undisclosed Location. Brian wants to move the servers to a linode on which Brian has root and Zooko hasn't. Zooko feels defensive and polarized about the prospect of giving up control of his carefully configured tools. A company who I don't know if they want to be named has offered to donate a few servers for our use. Lots of options; it'll all work out somehow. I personally hope that we can leave well enough alone until after 1.8β and that Peter's router is in a good mood this coming weekend. In other news some people want to donate money to Tahoe-LAFS. That is very nice of them! That makes us feel loved. And we could use the money for stuff like buying a new router for Peter's Undisclosed Location. (If that turns out to be the problem.) Unfortunately Paypal won't let people donate to us until we prove to them that we're a non-profit. Peter is working on paperwork so that we can get paid by Paypal, by the Google Open Source Programs Office (for GSoC), and by Flattr users. That last thing is deeply cool (remember Mojo?) and I will write a separate letter about it as soon as it comes to fruition. Also, I applied to the Software Freedom Conservancy [6] for Tahoe-LAFS to be a Member Project. The Conservancy would facilitate paperwork of the aforementioned kind (accepting donations, filling out tax forms, etc.) as well as helping with software licensing, project governance (who's in charge here anyway?) and so on. They appear to have a good habit of helping their projects implement the policies that the project already chose instead of imposing their policies on the project. There is a potential sticking point—they will probably have to ponder deeply what they think about the Transitive Grace Period Public Licence [7]. I'm hoping that they conclude that they can make us a member project without requiring us to change our licensing, even if they have reservations about the TGPPL. (I would be extremely reluctant to stop offering Tahoe-LAFS code under the TGPPL. I think the TGPPL is a beautiful idea, if I do say so myself.) = Big Picture Stuff = What do we want out of Tahoe-LAFS for the rest of 2010 and for 2011? Oh shoot it is way too late to go into this now. Let me know what *you* want out of Tahoe-LAFS for the rest of 2010 and for 2011! :-) Regards, Zooko [1] http://tahoe-lafs.org/trac/tahoe-lafs/roadmap [2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/how_to_make_a_tahoe-lafs_release.txt [3] http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004794.html [4] http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004817.html [5] http://tahoe-lafs.org/pipermail/tahoe-dev/2010-July/004712.html [6] http://conservancy.softwarefreedom.org/ [7] http://tahoe-lafs.org/~zooko/tgppl.pdf http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393# mutable: implement MDMF http://tahoe-lafs.org/trac/tahoe-lafs/ticket/798# improve random-access download to retrieve/decrypt less data http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1074# get rid of tahoe.exe launcher http://tahoe-lafs.org/trac/pycryptopp/ticket/18# AES-CTR: easy way to modify the counter for random-access decryption http://tahoe-lafs.org/trac/pycryptopp/ticket/34# Segmentation Fault in function X86_SHA256_HashBlocks http://tahoe-lafs.org/trac/pycryptopp/ticket/37# Win64 and MSVC9 compilation fixes http://tahoe-lafs.org/trac/pycryptopp/ticket/43# add a quick start-up self test for SHA-256 http://tahoe-lafs.org/trac/pycryptopp/ticket/44# test what happens if another Python module loads Crypto++ dynamic link library http://tahoe-lafs.org/trac/pycryptopp/ticket/45# upgrade to latest Crypto++ with SHA-256 bugfixes _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
