Release engineering for 2.2 coming up - UPDATE1

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    We are still working on a few installer and nrelease build issues.  I
    hope to be able to branch 2.2 this weekend or early next week, and the
    actual release will occur about 2 weeks after we branch.

    We are going to have a mini-freeze of the current development branch
    during the release engineering cycle this time to make it easier to
    merge work into the release branch.

    The 2.2 release cycle will feature our conversion over to the GIT
    source control system, with git support binaries included on the CD
    (built from pkgsrc of course), and the release of a new DVD ISO image
    containing all sorts of pre-built packages in addition to the
    bare-bones CD ISO that we always release.

    A great deal of work has gone into this release, I haven't organized
    a list yet but the high points include many bug fixes, scheduler
    improvements, network driver and protocol improvements, more wireless
    work, improved SATA support, improved pkgsrc compatibility,
    a very stable HAMMER filesystem, and many other things.

    --

    HAMMER will be very stable in the 2.2 release and the installer will
    have a HAMMER option for new installations.  HAMMER has been running
    in production on several heavily-used dragonfly boxes since around last
    July with no media corruption.  Heavier and heavier testing regimens
    are being used to squeeze out remaining bugs.  Currently there are
    two known bugs remaining of which one will be fixed for this release.
    The last bug is a very rare assertion in the B-Tree code which has
    not yet been tracked down.  None of the bugs found since the 2.0
    release corrupt the media.

    I had a bit of writer's block and didn't finish the hammer fsck
    utility.  I really wanted to get it done but certain worldwide events
    have been eating a lot of my time since October, and will continue to
    do so for the next few months.  The work load should trail off as time
    progresses and I hope to have the hammer fsck utility done in the first
    half of this year.

    There is also a minor performance issue with very large directory
    scans which I originally thought was due to the way the directory
    hash worked, and I had hoped to fix it for this release.  The problem
    turns out to be more complex, related not so much to the directory
    hash but instead to a lack of correlation between the directory scan
    order and inode numbers which cause extra I/O's due to reduced locality
    of reference.  Simon and I are running through some ideas on how to
    improve it for 2.4.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>