Re: Stable tag will be slipped Sunday and release engineering wi
: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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 6 之 49 篇)：