Welcome to the Tahoe-LAFS Weekly News (TWN). Tahoe-LAFS is a secure, distributed storage system. View TWN on the web or subscribe to TWN. If you would like to view the "new and improved" TWN, complete with pictures; please take a look.
There is a Tahoe-LAFS Users Group meeting this Tuesday in San Francisco. A big thank you to Rackspace for providing the space and the food from Goat Hill Pizza. There are three items on the agenda: announcing Tahoe-LAFS v1.10, Tahoe-LAFS for engineers who don't care about security and what should we put into Tahoe-LAFS v1.11? If you are in the area, I highly encourage you to make the meeting. It will be a blast.
As described later in the newsletter, the public grid is gaining some traction. The public grid provides a space for users new to Tahoe-LAFS a safe space for expermination and learning. I personally would like to extend a thank you to Paul Rabahy and the other volunteers for providing this service. If you can spare a node, please donate it to the public grid. You will be helping Tahoe-LAFS grow.
JoePie91 who runs the Cryto Coding Collective and its associated grid has established a new site, ReDonate
"ReDonate is a service for 'voluntary recurring donations'. What this means in simple terms, is that we allow you to set up recurring donations to a service, without ever making an automatic charge.
ReDonate works much like a calendar application - every month, you'll receive an e-mail reminding you of your pledge. The e-mail will include donation links, so that you can make the donation you pledged, straight away.
If you want to skip a month or even unsubscribe from a donation campaign, that's fine! There are no hoops to jump through, no cancellation periods, and no other kinds of hassle involved.
Basically, it's recurring donations how they were intended - as a voluntary periodic contribution to a campaign. No automatic charges, no subscription lock-ins, no other nasty things." [0]
Tahoe-LAFS is proud to be one of the initial campaigns along with Torservers and others. Thank you to JoePie91 for running this service.
A wonderful thing happened on Twitter. While discussing using Duplicati's ability to use Tahoe-LAFS as part of my backup solution, my friend w03 stated he would like to setup a test grid at his employer, Greenqloud . He tweeted he needed to run the idea past management in the morning. Here was Greenqloud's response
"just do it" [1]
Thank you to Greenqloud for being open to exploring Tahoe-LAFS. We appreciate it. Looking forward to any feedback you can provide.
Below are Zooko's meeting minutes from the Weekly Dev Chat.
in attendance: Oleksandr, Zooko (scribe), David-Sarah, Randall "ClashTheBunny" Mason, Brian (late—one lash), Tony (late—one lash)
not in attendance: Andrew (ABSENT—two lashes)
sort-of-in-attendance (on the IRC channel): a lot of folks
Agenda: Tahoe-LAFS v1.10 (Nuts and Bolts)
SUMMARY:
This was awesome. We got lots of tickets closed, or at least pushed forward a step or two. This was the most productive hour of ticket-closing work ever. We're going to do it again next week! If you like doing code-review and writing unit tests, you should join us.
DETAILS:
You can see also use the Trac Timeline:
https://tahoe-lafs.org/trac/tahoe-lafs/timeline
ClashTheBunny has some patches for IPv6 for Tahoe-LAFS and Foolscap (#867), and has some tests of them but needs more thorough tests. However, we didn't look at that this time, because we focused on tickets for Tahoe-LAFS v1.10.
Nejucomo said on IRC that he wasn't going to get around to manually verifying that the bug we fixed in ticket #1679 was the same as the bug he reported. I decided to just close the ticket for the following reasons: there is a bug that we understand, there is a fix which is clear, there is a unit test that exercises the bug that is red without the fix and green with the fix, and The Dod manually verified that it fixed the problem in practice for him. The only reason we've left the ticket open waiting for Nejucomo to test is in case Nathan actually has a different bug than this one. But we don't need to keep the ticket open for that eventuality.
ClashTheBunny did design review on #1732. He approved the design and made good comments that showed that he actually had thought about it. Subsequently Zooko added another design question and assigned it to Brian for design re-re-re-review.
We looked at #1926. It is a blocker because it makes the SFTP frontend incompatible with the current stable release of Twisted. However it is closed as a duplicate of #1525 because the improvement in #1525 would remove the incompatibility. We briefly considered kludging it by requiring people to install an older Twisted, but instead decided to fix it the good way. David-Sarah had already implemented the fix to #1525 but there was something wrong with the unit test.
NEWFLASH! This just in! As we were going to press, David-Sarah posted on #1525 a comment that they are currently working on it.
We discussed #1767. David-Sarah had an idea for how to make the implementation simple, by incrementing the server-wide counter once for each service. Brian will work on it. It and #1732 are the two blockers that require new code to be written before we release Tahoe-LAFS v1.10.
We closed #1484 as fixed. Yay!
#1746 is finished, reviewed, and ought to go into Tahoe-LAFS v1.10, but I can't figure out how to merge it into master using git. I don't understand how to use git very well, since I've only been using it on a daily basis for a little more than two years now...
#1812 was already applied, but there was something wrong with it according to Brian. Do we need to fix that as a blocker for 1.10 release?
We agreed to drop support for Python 2.5 and therefore for CentOS 5.
In the last few minutes of the hangout, we agreed that next week's hangout will be another Nuts And Bolts like this one, hopefully bringing Tahoe-LAFS v1.10 close to completion. Brian will work on #1767. Someone (maybe Zooko??) will work on #1732.
Then we briefly mentioned the possibility of switching from a "semantic versioning" style version number, to a YEAR.RELEASE_COUNT version number like Twisted does. So instead of Tahoe-LAFS v1.10, this might be Tahoe-LAFS v13.0. Then if there is another release in 2013, that would be Tahoe-LAFS v13.1. We also considered leaving it alone for the "v1.10" release, and switching styles for the next release.
Currently we use the "1." in "Tahoe-LAFS v1.10" to mean that it has backward-compatibility with all of the stable Tahoe-LAFS releases since v1.0 (released March 25, 2008: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc#TheParadeofReleaseNotes ). I'm not sure that's accurate. While we have never deliberately violated that goal, and we are not aware of any change that we've made which would break that compatibility, on the other hand we don't have automated or manual testing of backwards compatibility. Anyway, I suspect that there aren't any users of Tahoe-LAFS versions older than 1.9.2: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OSPackages
tickets mentioned in this letter:
Below is Paul Rabahy's monthly status of the public grid.
"The new public grid appears to be gaining traction quite well. I figure now that it has been in operation a little more than a month it would be good to give a quick overview of its status and any other observation that I have had.
I want to thank the storage nodes that have been reliably connected including the following: claude kapiteined rebuilder_tx PRabahy wander pubgrid-ecd10741
The public writable test directory has been used by several people (including myself) for various experiments. So far I haven't noticed any abuse."
"Currently the shares directory on the PRabahy node weighs in at about 650MB. The largest individual share is about 172MB (~25% of the total stored).
I encourage everyone that is able to setup a storage node to help newcomers dive into Tahoe-LAFS as easily as possible. My goal is to have at least 10 storage nodes connected to the public grid at any time.
Warning - The public grid is a service provided for experimentation and learning. Please do not store any important files on the public grid. The grid may go offline at anytime without prior notice."
This issue's glowing quote is a little different. It comes from inside Tahoe-LAFS, but I feel it really hits on something really awesome about Tahoe-LAFS.
"A 20-minute demo of installing the Tahoe-LAFS software, deploying a grid of storage servers, using them to upload, download and browse files. Then the punch line: did you notice what we didn't do during this demo? Screw around with certificates, keys, encryption, or decryption! You don't have to spend your time messing with that stuff in order to use Tahoe-LAFS." - Zooko Wilcox-O'Hearn [2]
Awesome, my UI redesign finally landed in @tahoelafs: https://github.com/tahoe-lafs/tahoe-lafs/commit/709be93a29e20026e61a436dac3fa1c160e9cef2" [3]
There are five (5) ticket still needing review for 1.10.0:
There are six (6) tickets still needing review of 1.11.0:
The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS Software Foundation, President and Treasurer: Peter Secor . Scribes: Patrick "marlowe" McDonald , Zooko Wilcox-O'Hearn , Editor Emeritus: Zooko. View TWN on the web or subscribe to TWN . Send your news stories to marlowe@antagonism.org — submission deadline: Friday night.