Date: Tue, 16 Sep 2008 02:48:15 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Andrew Snow <andrew@modulus.org> Cc: Mark Linimon <linimon@lonesome.com>, freebsd-stable <freebsd-stable@FreeBSD.org> Subject: Re: Upcoming Releases Schedule... Message-ID: <20080916094815.GA60168@icarus.home.lan> In-Reply-To: <48CF7394.8040707@modulus.org> References: <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <F17BE4F1F989BB4A81EB94C36712A9736F3493@dni-mail.datanode.com> <20080904133604.GB1188@atarininja.org> <CB36FE28-D125-4C22-B5DE-1001515DD8A6@netconsonance.com> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <alpine.BSF.1.10.0809061159410.28840@fledge.watson.org> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <48CF5282.10608@modulus.org> <20080916065657.GB12295@soaustin.net> <48CF7394.8040707@modulus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080916094815.GA60168>