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? _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
