From owner-freebsd-stable@FreeBSD.ORG Sun Jun 8 15:52:38 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 1174E1065670; Sun, 8 Jun 2008 15:52:38 +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 B4E9E8FC1A; Sun, 8 Jun 2008 15:52:37 +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 0B45246C06; Sun, 8 Jun 2008 11:52:37 -0400 (EDT) Date: Sun, 8 Jun 2008 16:52:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Josh Carroll In-Reply-To: <8cb6106e0806071938x6a524ba4o969fbc4f0c85206@mail.gmail.com> Message-ID: <20080608164928.L16871@fledge.watson.org> References: <8cb6106e0806071938x6a524ba4o969fbc4f0c85206@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adrian Chadd , FreeBSD Stable Subject: Re: 6.2; 6.3; EOL; combustible discussions 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: Sun, 08 Jun 2008 15:52:38 -0000 On Sat, 7 Jun 2008, Josh Carroll wrote: > While it would be interesting to see the response here, it still doesn't > necessarily provide a solution. It will still involved developers' time to > QA the user-submitted patches, so it won't entirely eliminate the additional > workload for maintainers. There is also zero (enforceable) accountability. > If X people commit to this, what happens when only a fraction of them > actually do end up helping? Just to be clear here, Adrian's claim that if someone else provided patches for 6.2, they would be committed, is incorrect. The cost of committing the patch is almost zero -- the cost of QA'ing the patch, doing freebsd-update rebuilds, preparing security or errata notices, etc, is extremely real, and the reason that we carefully limit the number of releases we support at once. In fact, I'd argue that we have been supporting too many releases at once, as I think our latency for shipping errata notices and advisories is too high. By reducing the number of releases we support, we improve the speed and attention we can give each notice/advisory, which is an important consideration. Robert N M Watson Computer Laboratory University of Cambridge