Moving to Git

Tahoe-LAFS is moving to Git. The repo lives on Github under the Tahoe-LAFS organization account.

Tahoe-LAFS will run both darcs and git in parallel for a while. Below are the restrictions on what we can currently commit:

• The bridge only handles linear histories. Brian will enforce this by rewriting and rebasing any changes that enter from the Git side before landing them on master. Patches coming from the Darcs side are applied in single-file anyways, so no new restrictions there.
• Brian runs the bridge manually (it's not safe enough to be run unsupervised), so there will be a human delay between the time something lands on the darcs side and the time it appears on the git side. Brian usually gets to it within a day, but feel free to ping him on IRC when you push a commit to darcs.
• Nobody else should commit to the official git repo right now. When we stop using darcs (and the bridge), we can fix the permissions so that all Tahoe committers will have write access. Send pull requests and Brian will merge them appropriately.
• Release branches will have to be managed specially. 1.8.3 does not yet exist in the git repo (Brian will need to build it manually). If we do a near-term 1.9.1 release, we'll probably do it from trunk.

Tahoe-LAFS has a new buildmaster, which feeds off the Github post-commit hook, and instructs buildslaves to update from Github. We'll be moving all the existing slaves to this buildmaster, and then we will determine which ones need to have Git installed (or their buildbot code updated). We'll also update to a newer buildbot version (0.8.5) at the same time, and start using "categories" to organize the waterfall views a bit more easily.

The developers also moved pycryptopp to Github. The buildbot now draws from Github, and all but one of the buildslaves upgraded to match.

"The first pull request has been merged, to fix compile errors with the upcoming gcc-4.7.0 release. The second pull request, to add Ed25519 signatures, is under review by Zooko." [1]

1.9.1 Release

Brian announced the upcoming 1.9.1 release. The team hopes to release 1.9.1 in the next couple of weeks. The main drivers for this release are:

• #1628: UCWE on deep check with recent version
• upcoming Ubuntu LTS freeze. We hope to get this fix in before the freeze

Ticket 1628 needs review, so please review the ticket.

In addition, some other changes have occurred since the 1.9.0 release which will be included in 1.9.1:

• the download-status timeline visualizer was rewritten
• the WUI got a favicon
• OpenBSD 5 support was added
• PyCrypto 2.4 was blacklisted
• some internal refactoring

The changes will be included in the 1.9.1 release.

The following tickets are part of the 1.9.1 milestone:

• #1212: Repairing fails if less than 7 servers available
• #1636: Unhandled error in Deferred while uploading (current darcs build)
• #1637: compilation errors with pyOpenSSL >= 0.13 on RHEL5 systems (and clones)
• #1643: presence of MDMF in aliases break the CLI < v1.9.0
• #1648: assertion failure 'assert len(self._active_readers) >= self._required_shares' in mutable retrieve

TWN Scribe Strives to Become Developer

With the coming of the new year, I (Patrick ) decided to seriously pursue my goal of learning programming. Further inspired by Zooko's tweet,

"Congrats!! Submit a patch to Tahoe-LAFS! We offer mentoring by experts to all contributors. :-)" [2]

What better way to learn a language than to work on real problems rather than sample exercises and have the support of some of the best programmers? Plus you get to learn the other details of being a developer: updating tickets, submitting patches, responding to comments, etc. So I decided to take Zooko up on the offer. I am searching through the easy tickets to determine which will be my first try. I can't wait to get started.

Tamias

Jean Lorchat announced the beta release of Tamias .

"The Tamias Project is an attempt to create an opensource, privacy-aware distributed file storage. When ready, Tamias will provide :

• Secure and reliable storage for all kind of files
• Easy sharing with per-object control and container objects
• Storage provider independence

Tamias is based on the Tahoe-LAFS storage system and borrows it’s secure properties while leveraging a public-key infrastructure on top in order to provide distributed access control.

Why “Tamias” ?

The Tahoe-LAFS system is based on capabilities, which are very important and impossible to remember, which means you have to write them down somewhere and mail them around. When looking for shares, users then look like a squirrel looking for acorns. Tamias are a kind of chipmunk." [3]

Tahoe-LAFS devs look forward to learning from Tamias' thought processes, implementation, and any feedback from their users.