From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 19:42:00 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 02B2D1065677 for ; Mon, 22 Sep 2008 19:42:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AFADC8FC15 for ; Mon, 22 Sep 2008 19:41:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 49CF746B2A; Mon, 22 Sep 2008 15:41:59 -0400 (EDT) Date: Mon, 22 Sep 2008 20:41:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jo Rhett In-Reply-To: <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> Message-ID: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> <34C3D54B-C88C-4C36-B1FE-C07FC27F8CB5@netconsonance.com> <58B648A5-4F9D-4C02-9A1C-21E1294DEB7A@netconsonance.com> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable , Lowell Gilbert Subject: Re: Upcoming Releases Schedule... 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: Mon, 22 Sep 2008 19:42:00 -0000 On Mon, 22 Sep 2008, Jo Rhett wrote: > Again, what you are saying makes a lot of sense, and I have no problem with > it. We're just missing the crucial bit -- what is it going to take to reach > that goal? Regardless of commit bits, etc and such forth. Is 10 hours a > week of one person enough? Does it really need 4 people with 10 hours a > week? How do we get from here to there? > > This is where I think we're missing each other. Achieving a commit bit -- > sure, no problem with what you have outlined. But you haven't finished the > thought enough to confirm whether me having a commit bit would solve the > problem we are trying to solve. > > I mean honestly, is one person with a commit bit and some time enough to > solve the problem? I've been involved with enough projects to know that the > real answer might be, "no, we actually have all the people we need with > commit bits but our infrastructure makes doing this difficult right now". Lack of human resources, to use a vile term, is currently the limiting factor. What happens when that is cleared is another question, but in the end there aren't a whole lot of paths to greater efficiency here: for each vulnerability, we generally start with the HEAD of the tree working back by age, for each branch identifying: - Whether the vulnerability, or broad class of vulnerabilities, exists - If the same patch applies, whether it fixes all instances of the problem in the next branch as well - Generate commit candidate - Test builds and runs - Generate binary updates - Generate appropriate security advisory information This is an inherently manual process because security patches touch a variety of parts of the system and each has different implications, the tendency for vulnerabilities to come in classes, etc. None of us remembers the format string vulnerability's arrival on the scene fondly since it became necessary to modify the compiler to try to mechanically sweep the tree for similar issues, for example. The older a branch, the more likely it is that it requires a different analysis and a different patch, hence the sigh of relief when 5.x fell off the support list -- not because it was a bad branch, but because there was significant divergence and maintaining three active development branches at once (5.x, 6.x, and 7.x) was a serious stretch. Robert N M Watson Computer Laboratory University of Cambridge