GSoC Weeks 8 & 9

I've spent the last couple of weeks responding to code reviews and cleaning up my commit history. This included a significant consolidation of the #1382 patch, which can be found here. The patch is being reviewed and we have decided that it will be included in Tahoe 1.11.0. While users won't see much of a difference from the patch, file reliability will increase significantly.

We've also decided to include #1057 in 1.11.0, which will apply the servers-of-happiness test to mutable uploads. This will be a great win for end users because they won't be confused by the conflicting behavior of mutable and immutable files.

Along the same lines as #1382 and #1057, I sent some time trying to reproduce #1830, which is an issue with happiness settings. Users have reported instances in which their happiness settings are ignored and the uploader will use the default value of 7 instead. Sadly I couldn't reproduce the ticket with a unit test on trunk and I didn't find anything that looked suspicious when reading through the codebase. My unit test can be viewed on this branch. The ticket needs to be investigated some more before it is closed and if anyone is having this issue, please post something on trac so we can properly reproduce the bug.

I also wrote a patch for #671, which is to bring back the size limit option for storage nodes. This is something I have wanted ever since I started using tahoe, so it was nice to be able to scratch that itch. The patch relies on the new LeaseDB branch in order to calculate the amount of data stored on the given node, so the patch won't land until 1.12 because of a significant performance regression in LeaseDB. However, I have been testing the branch in production and it has unit tests, so if you are in need of this feature you should be okay using it.

Finally, I've spent some time improving the buildbot configuration for automated testing. My first improvement was to create a CouchDB instance at IrisCouch so that test results from the buildslaves will be uploaded to a central database. This data will be useful for tracking possible performance regressions over longer periods of time than one or two patches.