From owner-freebsd-current@FreeBSD.ORG Fri Jan 11 18:18:27 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F87116A41B; Fri, 11 Jan 2008 18:18:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id 5513313C448; Fri, 11 Jan 2008 18:18:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1JDOSY-000PJp-1b; Fri, 11 Jan 2008 13:18:26 -0500 Date: Fri, 11 Jan 2008 13:18:25 -0500 From: Gary Palmer To: Timo Schoeler Message-ID: <20080111181825.GB86111@in-addr.com> References: <47873B06.9010603@riscworks.net> <200801111058.m0BAwAMG001075@lurza.secnetix.de> <20080111140144.59498431.timo.schoeler@riscworks.net> <47876B39.3040703@FreeBSD.org> <20080111145128.abb76a0a.timo.schoeler@riscworks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080111145128.abb76a0a.timo.schoeler@riscworks.net> Cc: Kris Kennaway , freebsd-current@FreeBSD.ORG Subject: Re: FreeBSD's problems as seen by the BSDForen.de community X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 18:18:27 -0000 On Fri, Jan 11, 2008 at 02:51:28PM +0100, Timo Schoeler wrote: > Thus Kris Kennaway spake on Fri, 11 Jan 2008 > 14:12:25 +0100: > > > Timo Schoeler wrote: > > > > >> It will even go into the CVS tree (though probably not > > >> into GENERIC) if the source is clean, style(9)-compliant > > >> and well maintained. > > > > > > It should do with *one* exception: Every other, more important > > > problem (e.g. getting ZFS to v9) is *solved*. If this is the case, > > > import the USB christmas tree device driver and introduce > > > dev.xmastree.lamps.blink as sysctl, absolutely no problem. > > > > > >> But even if it doesn't go into the > > >> tree, that's not a big deal. For example, for several > > >> years I maintained some patches that improved syscons > > >> (kern/15436). They didn't go into CVS, but they worked > > >> fine for me and a few others. > > > > > > But I bet you would be fine with it in the tree as well as some > > > others, if not all others? If so, why didn't it get into the tree? > > > Maybe because some lower-priority USB christmas device driver was > > > imported instead? > > > > > > This is the crucial point I wanted to show: *Priorities*. > > > > You are making the incorrect assumption that one developer working on > > e.g. your /dev/uxmas in any way effects the development of other > > "more important" parts of the tree. > > No, I didn't. I said that the work is done ineffectively as he's doing > underprioritized stuff. Working on higher prioritized stuff would be > more efficient, and would help the project even more. > > Given the assumption that the developer is able to do both, the Xmas > tree as well as importing ZFS v9 into the tree. > > (I don't see the point that when somebody is really *capable* of doing > both things, why should (s)he do the 'lower priority' thing. If you > are at the olympic stadium and you're the best sprinter, you wouldn't > join the marathon...!) The assumption you are making is that someone working in the kernel is capable of working anywhere in the kernel (or equivalent code base). >From personal experience thats not true. The kernel is a very complex piece of code and I doubt any one person understands all of it. People who are working on a USB driver for Christmas tree lights probably are not capable (without a huge learning curve) of fixing race conditions in the virtual memory subsystem. I suspect that if you look carefully, most of the time the people who are capable of addressing the issues that are raised are doing so in whatever time they have available. The people who are not get on with whatever they were doing (such as writing a high definition audio driver). Gary