[tahoe-dev] plan for Tahoe-LAFS v1.6

[Zooko O'Whielacronx]

Folks:

It has been almost 3 months since Tahoe-LAFS v1.5 came out.  (See the
Parade of Release Notes [1].)

It is time to start making a new Tahoe-LAFS release!  And we need your
help.  Here's the plan:

 * what's new in this release

Mainly #607 (immutable directories), #778 (measure file health in
terms of servers not in terms of shares).  Also #637, #761, #771,
#814.  There are some cool hacks that aren't primarily in Tahoe-LAFS
itself, but still worth mentioning, such as #663 (ability to host bzr
repos on the Tahoe-LAFS grid).  In addition there are numerous small
issues that could be fixed without destabilizing the 1.6 release.  (If
I've forgotten anything please let me know.)

If you want to contribute any patches to Tahoe-LAFS v1.6, please do so
as soon as possible.  There are plenty of open tickets to give you
ideas -- start with "Easy Tickets" [2] or the 1.6.0 Milestone [3].

 * when can we release it

Let's try to finish the major features #607 and #778, and then spend a
couple of weeks on quality control.  Maybe we can release 1.6 by the
end of November.

 * quality

We need to take steps to ensure that v1.6 has the same high level of
quality that the previous releases did, or even better if possible.

This is very important. For a lot of people, the main appeal of
Tahoe-LAFS is the extreme reliability that you get from erasure-coding
your data across independent servers.  While the Tahoe-LAFS
architecture is perfect for this, it would be all too easy for a bug
or a UI issue to negate the architectural advantage.  The parts that
seem most vulnerable to me so far are the issues that would never
affect a Tahoe-LAFS developer but might bite an unwary user, such as
UI and server-selection.  That's why I think #778 is important.

To ensure another high-quality release, we need:

1.  To maintain thorough test coverage of all code touched by all
patches committed since v1.5.

2.  To automatically run all the tests on all the Supported Platforms
after each commit.  We have that, and I've been working with
buildslave maintainers to fix any unstable buildslaves and to deploy
new buildslaves.  If you would like to contribute a buildslave,
especially one that is not already represented on the Supported
Platforms list [4], please volunteer.

3.  To review new patches that have been contributed [5].  This is the
easiest way to contribute the most to Tahoe-LAFS right now -- spend 30
minutes or an hour reading a patch and it will help a lot.

4.  To review patches that Brian has already committed to trunk since
v1.5.  Brian has the special privilege of being able to commit patches
to trunk without submitting them for review.  He is an excellent coder
who consistently produces high quality work, but for added safety,
another pair of eyes should read the patches that he has committed and
look for mistakes.  Reading Brian's recent work won't be as easy as
reading the patches that are awaiting review, because Brian's patches
include large refactorings of the code.  It is, however, an
opportunity to learn software engineering from a master.

5.  To have a bunch of people manually test out the new version after
all unstable new features have been committed and before v1.6 is
released.  Everyone who cares can install it and make sure it that it
works at least as well as v1.5 did for all their needs.  This is the
reason that I would like there to be a couple of week "quiet period"
after the unstable patches have been committed and before we release
v1.6.

6.  To investigate all reasonable bug reports from the field.  I've
been working on this for the last few days and updating the relevant
tickets.  There are quite a few bug reports which we do not fully
understand what happened or how to reproduce it.  None of them appear
to threaten data integrity or confidentiality, but I would feel better
if we had a more thorough understanding of the details of Tahoe-LAFS
operations in the field.

Thanks for your help!  This is going to be a really good new
Tahoe-LAFS release.  :-)

Regards,

Zooko

[1] http://allmydata.org/trac/tahoe/wiki/Doc
[2] http://allmydata.org/trac/tahoe/query?status=%21closed&order=priority&keywords=%7Eeasy
[3] http://allmydata.org/trac/tahoe/roadmap
[4] http://allmydata.org/buildbot
[5] http://allmydata.org/trac/tahoe/wiki/PatchReviewProcess

tickets mentioned in this message:
http://allmydata.org/trac/tahoe/ticket/607 # DIR2:IMM
http://allmydata.org/trac/tahoe/ticket/637 # support "keep this much
disk space free" on Windows as well as other platforms
http://allmydata.org/trac/tahoe/ticket/663 # integrate a distributed
revision control tool with Tahoe
http://allmydata.org/trac/tahoe/ticket/761 # "tahoe cp $DIRCAP/$PATH
$LOCAL" raises AttributeError
http://allmydata.org/trac/tahoe/ticket/771 # tahoe ls doesn't work on files
http://allmydata.org/trac/tahoe/ticket/778 # "shares of happiness" is
the wrong measure; "servers of happiness" is better
http://allmydata.org/trac/tahoe/ticket/814 # v1.4.1 storage servers
sending a negative number for maximum-immutable-share-size?