Re: How do you make these huge changes and stay so stable?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I'm reading the diary, as well as the roadmap for the KVA/page
:requirements/requests and I'm wondering how the heck you can rip so much out
:and replace it with so much new code, and still stay 'production stable'?
:It's pretty amazing.  Do you guys just keep the patches to yourselves for a
:while to test them, or what?
:
:Jonathon

    Well, I don't think my own personal track record is *that* good.  But it
    is certainly a whole lot better then e.g. what we are seeing out of
    the FreeBSD developer base.  I've introduced plenty of bugs, as have other
    DFly developers.  The difference is that we are very focused on fixing
    the problems that crop up as priority #1... and doing it right, not just
    adding hacks to work around problems.  So there are usually only a small
    number of 'serious' bugs outstanding at any given moment.  We are very
    focused on producing maintainable APIs for subsystems... that is one of
    my biggest requirements for new code.  The result is a far more 
    maintainable code base then e.g. FreeBSD has.  And I wouldn't be saying
    that if I didn't think the evidence to the fact was incontroversial.

    I would hold up Jeff's SACK implementation as the poster-child here.
    Only three people really tested his code pre-commit, yet post-commit there
    was exactly *ONE* (and only one) serious bug exposed to our user base.
    And it was fixed very quickly.

    Regardless of how the performance numbers turn out when we finally turn
    off Giant (and I still believe that we are going to blow away the
    competition in that regard), our threaded-subsystem model has reaped 
    us *HUGE* rewards with regards to code development, stability, and 
    maintainability.  *HUGE*.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>