Re: implemented features (Re: Decision time....)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    I'll just say here that my particular psychosis when it comes to
    doing a project is, "if it's going to be done, it has to be done right."
    Even I recognize that this is not always the best path, but being able
    to enjoy the work is a major reason why I do it.

    There are fifty things I would love to see in the kernel, including
    finishing off the SMP support and doing an AMD64 port.  But many of
    those are things I would rather other developers do, particularly
    the SMP work for the network protocol stacks because its like 95% done
    already.  They are important, but if I spend all my time there then we
    won't have a new filesystem at the end of the year.  Having a new
    filesystem is a big ticket item for the project.

    In order to be able to work on the bits that are most important
    to my vision of the project I have to prioritize.  Right now my
    priorities are: GPT support, a new filesystem, and the clustering goals.

    I am very big on supporting other developer's work.  I'm there to help
    implement the supporting infrastructure and I am there to help finish
    off mostly completed work (such as NATA), and make it production-ready.
    I've just about handed SMP to people on a platter but so far no 
    developers have taken up the baton on that one (and as I said, the
    filesystem is more important right now).

    Well, not everything works out the way one hopes.  But I will remind the
    community that production stability is also extremely important to the
    project and there are certain pieces of infrastructure work, like SMP,
    that are very hard to do right and still have a stable system at the
    end of it (I think any FreeBSD developer can attest to that!).  There's
    no point having a feature if the result is an unstable system.  We
    have maintained most excellent stability in our releases and I think
    things can only get better as time passes.

    Consider for a moment that in one fell swoop just a short while ago
    (Feb-Mar), Simon and Thomas did an extremely major LWP commit that
    changed infrastructure in the kernel's handling of processes and
    signals and completed a MAJOR separation of the process structure.
    It went in so smoothly that there was nary a whimper on the lists.
    In fact, it went in so smoothly that I didn't even realize just how
    extensive the changes were until a few weeks later!  Process/LWP
    separation was a major infrastructure requirement for being able to
    make all the related code MP safe.  And maybe, just maybe, we now
    have two more developers who understand the kernel core well enough
    to do some SMP work (hint hint!) too.

    There is an excitement factor, too.  Who'd-a-thought one could switch
    libthread_xu and libc_r on the fly?  Now we can!

    In anycase, don't discount infrastructure work.  Infrastructure work
    turns out to be a major enabling factor for future development AND 
    for code longevity and stability.  We've reaped many benefits from
    the approach that aren't readily apparent to an end-user because the
    psychosis that an end-user has is that the system 'not crash'... but
    we developers know that making a system 'not crash' is a lot harder
    then it seems.

						-Matt