Stable tag will be slipped Sunday and release engineering will begin Monday

Matthew Dillon dillon at apollo.backplane.com
Sun Apr 3 12:43:16 PDT 2005


:One question which was not stated, but should be answered is what will
:trigger the creation of a FELEASE?  Did we just feel like it, or is it
:because USENIX was comming up :-)
:
:				Max

    We definitely need to get the release out before USENIX, which means we
    have one week.  I don't want to be handing out the now totally obsolete
    1.0A release.

    Generally speaking I'm thinking we should do a release twice a year.  So
    far we've been doing it approximately once every 9 months, which is a bit
    too long.  But no more often then twice a year because releases are
    supposed to be stable and doing a release too often both interferes 
    with development and creates a rush that leads to a less stable release.

    This is going to be an exciting year for DragonFly.  There are so many
    things that are on the cusp of becoming operational that this will likely
    be the *last* release that we make with subsystems still locked down by 
    the Big Giant Lock.

    * The networking code is --> <-- this close to being MP safe.  Jeff
      just finished MP'ing the route table (though I'm sure some minor work
      still needs to be done on it), and the only big items left to do are
      the mbuf allocator and firewall APIs.

    * The only big ticket item left in the mainline kernel is to thread
      the VFS and convert the VFS UIO API into an MSFBUF API.  Then we 
      can start turning off the BGL (and I'll probably start doing that
      sooner so it can be tested piecemeal).

    * There are lots of little-ticket items left in the mainline kernel,
      but all are in small easy-to-swallow chunks.

    The Journaling code will also definitely be finished this year.

    On the userland side, David Xu and Joerg have made phenominal progress
    on the userland threading support.  TLS storage already works, in fact.
    This will probably be the last GCC2 release.  After this release we will
    finish up the GCC3 support and migrate to GCC3 as the default.

    We still do not have an official packaging system, but David Rhodus and
    a number of other people now have significant experience and that may well
    dictate how we go on that.  Most people are already dependant on Dave's
    remote pkg_src repository :-).  I still want to create a VFS environment
    which guarentees the dependancies and can be used to build the packages,
    which requires a working nullfs filesystem.  I'm hoping I can get someone
    to work on a nullfs replacement.

    I consider this a 'clearing the decks' release.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list