My general opinion is that a developer should not claim ownership of
    anything, it should simply be apparent from the traffic the developer
    posts to the public lists, discussion, and his commits.  This implies
    that the developer is only actively working on one thing at a time,
    at least in regards to non-trivial projects, which further implies that
    the work can be committed in smaller chunks (or A smaller chunk) verses
    otherwise.  While this ideal cannot always be met I believe it is a good
    basis for people working on a large project without formal management
    (i.e. open source).  In the relatively rare case where a large rip-up
    must be done all at once an exception is made.   For the FreeBSD project
    such an exception would be something like CAM or KSEs, but virtually
    nothing else.

    As an example of this I will note some non-trivial things that I have
    done using this model:

        * Implementation of idle processes.  Anyone remember how long that
          took me?  It turned out to be a good basis for further work now
          didn't it?

        * Pushing Giant through (most of) the syscall code and into the 

        * The critical_*() patch is an excellent example of this.  The
          engineering cycle was 3 days (non-inclusive of all the crap that
          is preventing me from comitting it), and it is rock solid.

        * The rewrite of the swap system (In two pieces: added radix tree
          bitmap infrastructure, then switched out the swapper).  I think
          my engineering cycle on this was 1.5 weeks.  DG might remember

    So as you can see, from my viewpoint something like UCRED is just not
    that big a deal.  With the infrastructure incrementally comitted and
    in place the final UCRED pushdown is something one could write, test,
    and commmit, from scratch, in just a few days.  That is far more
    efficient then trying to keep it in a private tree for months on end,
    having to constantly sync it with code and algorithmic changes occuring
    in the rest of the tree.  The same can be said for many of the other
    subsystems sitting in P4, like preemption.  Experimental code has
    it's uses, but when I've gleened the information I need from one of my
    experiments I typically scrap the source entirely so it doesn't get in
    the way of other work.  Later I rewrite the feature from scratch
    when the infrastructure has developed enough to support it.  It may seem
    inefficient but the reality is that it speeds up my overall engineering
    and design cycles and, at least for me, the end result is pretty damn
    good code.  Because I typically focus on one thing at a time, 3 days
    to get something simple like critical_*() done often seems like an
    eternity to me.  I can't just switch my focus to something else,
    that isn't how I work.  I can do a few things in parallel, like help
    find bugs in this or that, but real engineering cycles I do one at a

    Personally speaking if I do something complex and instrumenting it
    is straightforward, I always go ahead and instrument it because it
    makes debugging by others easy.  That is why I have been and want to
    instrument Giant in the places where Giant is otherwise being removed,
    and why for example I had a sysctl to allow the critical_*() code
    behavior to change on the fly for testing purposes.  The thing about
    instrumentation is that it's easy to put in if you integrate it right
    off the bat, and utterly trivial to rip out months or years down the
    line when you don't need it any more.  I don't understand why people
    complain about 'putting in instrumentation that we'll just have to rip
    out later'.  That kind of attitude is tantamount to saying 'I'm not going
    to bother to make this code debuggable because I've found all the bugs
    in it'.  Yah, right.  From my point of view instrumentation reduces
    the overall time required to add and stabilize a new feature, whereas
    someone saving source lines by not instrumenting his code is simply
    setting himself up for a long, buggy engineering cycle down the line
    (and not being a good neighbor to his peers much either).  

    There is a damn good reason why I am rabid about instrumenting a
    complex piece of code.  I don't care *how* long a developer has tested
    a big piece of code, it is simply naive to believe that anything short
    of exposure to the entire development community will exercise the code
    enough to really give it a good test.  In that respect I have a strong
    dislike for the idea of sub-groups of developers testing a
    non-experimental feature (i.e. intended for commit) in a side-tree.
    I do not feel that it adds anything to the project and, in fact, I
    believe it is a detriment to the project.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to