From owner-freebsd-current Wed Feb 11 09:36:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA08018 for current-outgoing; Wed, 11 Feb 1998 09:36:21 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA08010 for ; Wed, 11 Feb 1998 09:36:15 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0y2g4k-0003Ni-00; Wed, 11 Feb 1998 10:35:58 -0700 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id KAA22807; Wed, 11 Feb 1998 10:36:07 -0700 (MST) Message-Id: <199802111736.KAA22807@harmony.village.org> To: Adrian Chadd Subject: Re: Hollywood (Re: PATCH.M ) Cc: Jonathan Lemon , current@FreeBSD.ORG In-reply-to: Your message of "Thu, 12 Feb 1998 00:55:15 +0800." References: Date: Wed, 11 Feb 1998 10:36:07 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Adrian Chadd writes: : I assume Terry wouldn't be putting forward patches that didn't work. And : hadn't been throughly tested. For some parts of the kernel there are additional requirements to amke sure that we're all haded in the right direction. Terry's patches are very interesting, but they are in an area that is hard to explain, as well as hard to understand. This presenets a barrier to having the patches included. I don't know the specifics of this, so I'll not speculate further on the interactions at work here. : If I mention VM code would someone kill me? :-) (Not taking a personal : attack at anyone here, so please don't read it as such.. :) : : Its not like stuff has been changed in -current before that hasn't : horrendously broken things in a big way and take ages to fix. My view of current is that things that should be in a future release of FreeBSD go there. If there are nit, bugs, crashses in the work that is committed, so be it. So long as those folks are comitted to fixing it or backing it out in a timely basis, I don't care if things are busted for a day or two here or there. The VM code I think is a special case. It is so complicated that it has to have lots of testers as soon as possible to shake out the problems. Also, the person making the changes has a stellar reputation for taking responsibility for making things work and has done some very impressive things in the FreeBSD world for a long time. If I were to start making such extensive changes to the VM tromorrow, I'd likely have multiple people ask me to prove myself (or at least my code) before it went in (and stayed in). However, no one seems to blink much when I commit buffer overflow fixes (even in large numbers of files) because I've done that many times. Sometimes I have the pointy hat thrust upon me for a commit that I've made, but in those cases I've always backed out the changes until I could fix the issue at hand. -current is for experimental things, but not too radically experimental. -current is the place for new ideas and code to mature, but isn't a dumping ground for all new code. There is a balance that needs to be maintained. This balance isn't always 100% technical. Sometimes there are polical reasons for doing things. lpr/lpd and sendmail come mind as programs that are known to be dangerous, but are still the best solution to the problems available given all considerations. Anyway, I'm not a core team member. These are just my views from interacting with the CVS tree for a long time and some private release engineerig philosophy that I've evolved in the jobs I've had over the years. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe current" in the body of the message