Upcoming Releases Schedule...

[Jeremy Chadwick]

On Tue, Sep 16, 2008 at 06:51:32PM +1000, Andrew Snow wrote:
> Mark Linimon wrote:
>> So, in your opinion, what's the way to reconcile all these demands
>> (features + stability + long-term support of release branches) with
>> a group that is 95%-plus volunteer effort?
>
> Its important to me that people keep using FreeBSD.  Numbers are  
> important.  To that end I'm happy for developers to keep working hardest  
> on the parts of FreeBSD they find most rewarding.  Something's got to  
> give and you can't stop it by creating more beaurocracy and red tape.
>
> Another thing I think is important is for new hardware to be perpetually  
> sent to those who can implement drivers and create patches.  I don't  
> feel the FreeBSD foundation is doing enough in that regard.  Not talking  
> about big ticket items like server farms, just new motherboards every  
> time a new CPU or chipset is released.

I agree with the last point.  However, a couple counter-points:

1) I believe this is what freebsd-donations@ is for (though I feel the
Foundation as a whole could be helping more with this),

2) Based on my own experience: I've offered to purchase new hardware
to send developers (free of charge), assuming I can get my hands on
whatever hardware it is they need.  I'm willing to spend a few hundred
dollars to get whatever it is they want, so financially I'm flexible.

Here's my experience:

What I'm finding out is that it's not the hardware developers need --
it's the time required to sit down and test everything and write the
code.  No matter what we do, we cannot create more time (or in some
cases, more incentives) for developers.  What we ultimately need is more
talent to make things better.

There's a number of people I see doing really good work, at least with
regards to RELENG_7 (I do not follow HEAD/CURRENT commits).  From what I
understand, all these folks are incredibly pressed for time.  I'll name
names, just because they deserve mention: rwatson, pjd, phk, jhb,
alfred, kmacy, kris, kib, yongari, scottl, Andrey Elsukov, and Max
Laier.  I apologise if I've upset anyone by this -- I'm not naming names
to "rank" people against others (it's a volunteer project after all),
I'm just listing off people who I've seen do really good work over the
past year or so, with regards to the few devices or kernel pieces I
actively follow.

For something as gargantuan/massive as an entire operating system and
all of its device support, there's a very small number of central people
doing regular work.  Compare this to Linux, where you've got:

a) 6-7 times the amount of kernel-people,
b) Commercial interest and support from companies (that means developers
are more likely to get documentation and development/test hardware from
the vendor themselves),
c) A significantly larger user-base for testing.

I have never agreed with Eric Raymond's "bazaar" concept, where the
attitude is "more eyes = overall better".  The problem in our case is
not lack of eyes, it's lack of hands and brains.  We have a lot of smart
people who aren't working on kernel-stuff because they lack the
experience/knowledge of how to get involved, where to start, and overall
understanding of the code.  I'm one of those people, for example.  I
do not understanding threading (the concept yes, the implementation no),
nor any "core" part of the kernel.

The most common rebuttal to this argument is "Well, there's <this web
page> and <this book>", but then when you try to follow either of them,
are later told "yeah, <page> is wrong, and <book> is completely out of
date, everything has changed".  It's demoralising.

I can sit down and within about 15-20 minutes have a minimum
understanding of part of a C userland program.  Comparatively, I have
looked at kernel drivers for hours without any understanding of what
numerous kernel ABI/API functions do, why they're being done, why
they're being done when they are.  I'm not even talking about
device-specific semantics (e.g. what does this IC register do, etc.).
I'm talking about the surrounding pieces.  I *have* hacked on the em(4)
driver, but all the surrounding pieces made me say "hmm, do not touch".
Any time I see the words VFS, BIO, mtx, or uma, I back off.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |