We are going to be shifting our master release schedule 2 months forward.

    This is being done for several reasons.  We will be releasing in

    September and March instead of July and January.
    This will give us a bit more time to sync up with pkgsrc quarterlies and

    also moves our releases out of the dead months (high summer and

    christmas) and into months where developers are more active.
    So we will be releasing 2.4 in September rather then this month.  There

    will be a lot of stuff in 2.4, and hopefully considerbly more by the

    time the release actually rolls around:
    * Jordan's AMD64 work: 64 cpu bit support for UP, hopefully 64 bit

      support for SMP.  Probably not 32 bit emulation under 64 bits by

      September though.
    * Alex's work: DEVFS.  I believe sufficient progress will be made in the

      next two months to make it useable.
    * Aggelos's NETMP work.
    * Sephe's network driver work and SMP work.
    * Sascha's installer improvements making a BOOT + HAMMER setup the

      default installation method.  Also fdisk can now be used on drives

      larger then 2TB and the kernel recognizes maxed-out fdisk parameters

      so disklabel64 will recognize the actual size of the disk if the fdisk

      slice is maxed out.
    * Additional work by me to help integrate serial number support into

      DEVFS (once Alex gets a little bit further on it), and adopting

      OpenBSD's /etc/devtab methodology.
      The serial number work is going to become *VERY* important as HAMMER

      development moves into the cluster-FS phase.  At that point drives

      will be able to exist anywhere on the network.  Even without that

      we have a real need to start addressing drives by serial number simply

      due to the fact that one can trivially connect many drives to the

      motherboard now via port multiplier enclosures.  Counting on the

      /dev/daXXX enumeration is simply not reliable.
    * 2.4 will feature a complete ...
[ message continues ]

This will mean the end of September and the end of March then - together

with Q3 and Q1 pkgsrc releases? This might be a little racy as well. It

might happen that pkgsrc release is delayed a little (like 2009Q2 is at

the moment) and it takes a while to build packages as well. We might play

with release/branch dates as well though - for example we branch when we

are ready and really announce a release when pkgsrc packages are ready.
And this will also mean that our userspace ABI/API/etc is unfrozen again.

I'd like to see it frozen again at least month before the release. So, at

max September 1, but better in August 15. Is it OK?
It should be enough, but I'm not sure of course. Let's see how this works.
--

Hasso Tepper

Pkgsrc releases happen every 3 months, so shifting our release over to

March and September means that we'll usually intersect with the 20xxQ1 and

20xxQ3 releases, instead of the 20xxQ2 and Q4 that we do now.  So, it'll

still be a little bit of a race between which quarterly build is done vs.

when we release, but this does give us more breathing room.