From owner-freebsd-current@FreeBSD.ORG Fri Feb 3 01:19:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55F8D16A420; Fri, 3 Feb 2006 01:19:42 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.200.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id C710043D45; Fri, 3 Feb 2006 01:19:41 +0000 (GMT) (envelope-from dougb@freebsd.org) Received: from [192.168.0.3] (c-24-130-213-251.hsd1.ca.comcast.net[24.130.213.251]) by comcast.net (sccrmhc11) with ESMTP id <20060203011934011004jbqbe>; Fri, 3 Feb 2006 01:19:37 +0000 Message-ID: <43E2AFA5.5000205@FreeBSD.org> Date: Thu, 02 Feb 2006 17:19:33 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Robert Watson References: <20060201221213.L87763@fledge.watson.org> <43E134AB.8000600@t-hosting.hu> <20060201222704.G87763@fledge.watson.org> <43E14C53.3060400@rogers.com> <20060202004044.GA99245@xor.obsecurity.org> <20060202004845.C87763@fledge.watson.org> In-Reply-To: <20060202004845.C87763@fledge.watson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mike Jakubik , K?vesd?n G?bor , current@FreeBSD.org, trustedbsd-audit@TrustedBSD.org, Kris Kennaway Subject: Re: HEADS UP: Audit integration into CVS in progress, some tree disruption 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, 03 Feb 2006 01:19:42 -0000 Robert Watson wrote: > > On Wed, 1 Feb 2006, Kris Kennaway wrote: > >>> Personally, i would like to see less "experimental" code in 6.1. >>> Perhaps it would be better to wait until everyone feels the code is >>> ready? >> >> Why do you care if code that is not enabled by default is present in >> the system? :-) > > Well, I think there are some potential risks. The main ones are: > > (1) That the unconditionally compiled bits cause problems. Primarily > this is > the audit support in login, sshd, etc. Apple has been running with > basically the same code for a couple of years now, but there is always > risk in change. > > (2) Risk to users who do try the experimental support and run into bugs, or > run into things that we will change for a 6.2 release as we fix > problems. I was with you right up until that last bit. Given that we are changing the release model to time-based releases as opposed to feature-based, the "danger" that we'll go a long time without users having access to new features is significantly lowered. Therefore, IMO we need to be even more careful about making sure that -stable branches stay stable; including A[BP]I issues. No matter how carefully we label something as "early adopter," etc; users of -stable are still going to complain if something they come to count on changes out from under them, and I have a lot of sympathy for that argument. My vote would be to leave it in HEAD until it's thoroughly cooked, then make the decision to MFC or not based on how close we are to 7-RELEASE. Doug -- This .signature sanitized for your protection