[tahoe-dev] now cooking: Tahoe-LAFS v1.8β

[Zooko O'Whielacronx]

Folks:

With a solid Tahoe-LAFS v1.7.1 out the door, we're immediately turning
our attention to Tahoe-LAFS v1.8β. What's going in? Well, of course it
depends on what people contribute, but it looks likely that Brian will
have some New Downloader Code ready (#287, #288, #448, #798, #800,
#809, #990, #993, and/or #1110). Also David-Sarah has a more-or-less
complete implementation of #1074 which should make the cli work on
win64 and support non-ascii command-line arguments and non-ascii
output.

Those two will be a good start to get us off on a new codebase
destined for 1.8β! We're going to commit those two as soon as they are
fully tested, reviewed, and (in the case of Brian's New Downloader)
measured for their performance impacts. That way we will have some
juicy new features sitting in trunk and we will be able to produce a
new release from trunk whenever we are ready.

In addition to those there is a chance that Google Summer of Code
student Kevan will have some subset of his MDMF project (#393) ready
in time for 1.8β and a good chance that Google Summer of Code student
Faruq will have some subset of his Decentralized Introduction project
(#68). Very exciting!

There are, of course, a huge number of other urgent and important
things that we need, notably Kyle Markley's desire to have uploads
succeed more often without leaving the shares distributed in a fragile
pattern (#1130) and François Deppierraz's nice graphical depiction of
an SFTP memory leak (#1045).

See the Roadmap — http://tahoe-lafs.org/trac/tahoe-lafs/roadmap — for
all of the numerous ways that you can help. See also the easy stuff
for people who are just getting started: Easy Tickets —
http://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~easy&order=priority
— and How To Review Patches —
http://tahoe-lafs.org/trac/tahoe-lafs/wiki/PatchReviewProcess .

Thank you very much for all help!

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement distributed
introduction, remove Introducer as a single point of failure
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/287# download: tolerate
lost or missing servers
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/288# resumption of
interrupted downloads
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393# mutable: implement MDMF
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/448# download: speak to
as few servers as possible
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/800# improve alacrity by
downloading only the part of the Merkle Tree that you need
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/809# Measure how segment
size affects upload/download speed.
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/990# Web gateway should
avoid caching plaintext of downloads
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/993# refactor download
interfaces to treat immutable files and mutable versions more
uniformly
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1045# Memory leak during
massive file upload (or download) through SFTP frontend
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1074# get rid of tahoe.exe launcher
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1110# pipeline download
blocks for better performance
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1130# Failure to achieve
happiness in upload