[tahoe-dev] Alpha1 tagged! 1.9.0a1 tarball available!

[Brian Warner]

This morning I finally tagged 1.9.0a1, available as a tarball in here:

  http://tahoe-lafs.org/source/tahoe-lafs/tarballs/

  (look for allmydata-tahoe-1.9.0a1.tar.bz2, or .zip, or -SUMO.zip if
  you want the dependencies too)

or through version control with:

 darcs get --lazy --tag=allmydata-tahoe-1.9.0a1
http://tahoe-lafs.org/source/tahoe-lafs/trunk tahoe-lafs-1.9.0a1

or

 git clone git://github.com/warner/tahoe-lafs.git
 cd tahoe-lafs
 git checkout allmydata-tahoe-1.9.0a1

We landed Kevan's MDMF work (a new mutable file format) (#393), as well
as the storage-index -based blacklist support (#1425), and David-Sarah's
experimental "drop-upload" feature (#1429). Relative to 1.8.2, there's
also my immutable-download Timeline visualizer (#1200), and a whole
bunch of internal build/packaging/test improvements and cleanups.

We have *not* yet updated the release documentation (NEWS,
quickstart.rst, etc) to reflect the new version. In addition, we're
still working on some gaps: MDMF isn't supported in 'tahoe debug
dump-cap', some of the controls that let you upload as
immutable/SMDF/MDMF need tweaks, etc.

We need your help to test this! In particular, because the MDMF code
subsumes the old SDMF uploader/downloader, we're specifically concerned
about potential regressions in existing mutable files. Please test as
many combinations as you can: create mutable directories with the new
code and make sure you can read/write them with the old code, and vice
versa. Also upload larger mutable files and then download them with a
web browser, and with tools that will exercise random-access patterns
(via the HTTP "Content-Range:" header): the code that retrieves portions
of the file (as opposed to the whole file) is particularly tricky and
might contain new bugs. Also please exercise the pause-download feature:
download a large mutable file over a slower link (so the gateway
produces data faster than the downstream link can accept it), and make
sure the whole thing gets through eventually.

We're looking for test coverage of MDMF too, but since MDMF will still
be opt-in for 1.9 (we'll probably make it the default in 2.0), we're
most concerned with SDMF right now. We'd be willing to ship 1.9 with
minor problems in MDMF, but any regression in SDMF will block the
release.

Our 1.9 schedule keeps slipping, but here's the current plan:

 * spend a week or two fixing up the gaps in MDMF and testing
 * if all goes well, cut a beta1 around September 10th
 * finish updating the docs, test packaging, update dependencies
 * cut an rc1 around September 24th
 * make the final release around October 1st


inching ever closer to a release,
 -Brian