From owner-freebsd-stable@FreeBSD.ORG Wed Jun 11 15:49:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A4151065676 for ; Wed, 11 Jun 2008 15:49:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id EE4A18FC16 for ; Wed, 11 Jun 2008 15:49:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9D37346B88; Wed, 11 Jun 2008 11:49:49 -0400 (EDT) Date: Wed, 11 Jun 2008 16:49:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Anton - Valqk In-Reply-To: <484FA07E.60103@lozenetz.org> Message-ID: <20080611164704.J40102@fledge.watson.org> References: <3cc535c80806080449q3ec6e623v8603e9eccc3ab1f2@mail.gmail.com> <484FA07E.60103@lozenetz.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andy Kosela , freebsd-stable@freebsd.org Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2008 15:49:51 -0000 On Wed, 11 Jun 2008, Anton - Valqk wrote: > I fully agree with the lines below. > As noticed below there is more attention to developing new features, > than making releases rock solid stable. ... > Ah, another thing, > I'm waiting for virtualization networking layer for jails for quite long. > I've tested it on a test server, worked perfect, but on production I don't > want to patch my base. > there are few other features to jals that never got commited in base, and as > I said I don't want to patch it... The reason that the virtualization patches aren't in the tree is precisely *because* we care about stability and are willing to slow down feature development in order to accomplish it. Some features take years to stabilize, and just because a patch works OK in your environment doesn't mean it will work in everyone's. Moderating the rate at which we adopt agressive new features is part of an intentional strategy to avoid letting development trees destabilize to a point where it's unproductive. Robert N M Watson Computer Laboratory University of Cambridge